Are HD audio encoders/decoders really lossless?...

[Marin85]

Hi,

first of all excuse the slightly provocative character of the title I think the question is very real, so please bear with me. I have recently played a little bit with one of those blu-ray discs that are intended for testing and adjusting one's HT setup. In particular, this disc contains the same piece of classical music as 3 different tracks, LPCM 5.1, DTS-HD MA 5.1 and TrueHD 5.1, which is perfect for all sorts of comparisons, so I decided to make two simple tests. I extracted all three audio streams and transcoded them into wav. For the DTS-HD MA track I used eac3to + Arcsoft DTS Decoder 1.1.0.8 and for the TrueHD track I used eac3to + the default ffmpeg decoder. Then I put them through SoundForge and its spectrum analyzer. This is what I get:

DTS-HD wav vs. LPCM wav vs. TrueHD wav


Given that the LPCM track, being uncompressed, is as closest to the studio audio as it gets, I found it kind of surprising to see such differences in the spectral shots.

Now, since I don't know anything about the production background of this benchmark blu-ray disc, I decided to perform a second test, this time with some transcoding via the DTS Master Audio suite. So, I took the LPCM and DTS-HD MA wavs, then transcoded them to DTS-HD MA 5.1 tracks via the DTS MA suite and then transcoded them back to wavs via eac3to + Arcsoft DTS decoder 1.1.0.8 to make again some spectral shots. Here is what I got:

DTS-HD MA wav track obtained from the original DTS-HD wav via DTS MA suite + Arcsoft DTS decoder vs. the original DTS-HD MA track


DTS-HD MA wav obtained from the original LPCM wav via DTS MA suite + Arcsoft DTS decoder vs. the original DTS-HD MA wav track


DTS-HD MA wav obtained from the original LPCM wav via DTS MA suite + Arcsoft DTS decoder vs. the original LPCM wav


If the DTS-HD/TrueHD encoders are lossless and if the ffmpeg audio decoder and Arcsoft DTS decoder v1.1.0.8 are also lossless, then I fail to see where such differences in the spectrograms come from. Maybe my method or my understanding or both are inaccurate, so I would appreciate any comments. Also, I know that when I encode wav into FLAC, the spectrograms match at 100% (which is also expected).


EDIT: All encoding with the DTS MA suite has been done with no attenuation and at the original sample rates of 48 kHz.

[rik1138]

Try a binary compare:
Take your WAV file, encode it to DTS-HD MA. Decode it back to a WAV file and compare the original WAV file with the new one.
With the possible exception of a header, they will be 100% identical (I've tested this myself), thus it's lossless...
Not sure what other proof you would need...

For archiving audio, that's the whole point of DTS' Master Audio. The format can be used to archive source audio, and restore it back to it's original state.

Not sure how the analyzer graphs are generated, possibly after digital to analog conversion? If you analyze the same .wav file over and over, do you get the exact same graphs?

[Marin85]

Thanks for your reply! I have not thought of binary comparison yet since I trust(ed) the wave analysis, but this is now definitely something I will try. The procedure WAV -> DTS-HD MA -> WAV has been performed in the last comparison, where the spectral shots are different again. I will try a binary comparison with those two files tomorrow and will report back.

As for the graphs, yes, if I analyze the same WAV file over and over, I get identical graphs. Also, when I transcode WAV to FLAC, I get exactly matching graphs, too. Otherwise, the spectrum analyzer of Sound Forge would have been kind of pointless

I know what the point of DTS-HD MA is, but the above comparisons made me highly suspicious...

Update: I did a fast binary comparison of the files from the last comparison shots and they are certainly not identical, even though their size is. Maybe the problem is with Arcsoft DTS Decoder v1.1.0.8. I will try v1.1.0.0 and report back.

[Midzuki]

Yes, binary comparison is the (only) way to go.

FWIW, and so far, I am pretty sure the ArcSoft DLLs (both 1.1.0.0 and 1.1.0.1) canNOT decode stereo Master Audio losslessly.

[Marin85]

Update: I have tried v.1.1.0.0 of Arcsoft DTS decoder. The WAV output is identical to the one of v1.1.0.8, however both are different from the LPCM WAV input of the DTS MA suite. Now, the more confusing part is that SoundForge produces different spectrograms for the WAV output of v1.1.0.0 and v1.1.0.8... I will continue with the binary comparisons tomorrow.

[shon3i]

As rik1138 already explain

With the possible exception of a header..

[rik1138]

Yeah, try a couple of things:
First, your source WAV files need to be individual mono files.
After decoding back to WAV files (individual mono files if possible, if not then split into mono files with Audacity or something), and then compare the files visually in a hex editor or something...

For some reason, multi-channel WAV files seem to have differences throughout (if I start with a stereo WAV, and use eac3to to extract to a stereo wav, there's lots of differences in the files. I think there's header info on every audio frame that's different). If I start with a mono Left and Right WAV, and then use eac3to to extract to 'wavs' (producing two mono wav files), they are identical with the exception of a few hundred bytes added at the beginning in the header. If I delete that header, the files compare perfectly.

There just seems to be more header or 'user data' or something in multi-channel wavs than in simple mono ones. (And my eac3to is using the ArcSoft DTS decoder, not sure what version though)

[Ghitulescu]

It's not always evident, but there might be differences between those 3 tracks, even if they come from the same master (uncompressed). It's due to how the encoders work and what requirements they may have. Binary comparison will fail if one of the tracks has been slightly normalised before compression.

[pandy]

truncation/requantization - dithering/noiseshaping?

[Ghitulescu]

The only way the OP can prove his assertions is to take an uncompressed WAV and to encode it then decode it using the codecs of concern. Then the simple FC /B file1 file2 will tell him whether the codecs work indeed losslessly.

[rik1138]

Originally Posted by Ghitulescu

The only way the OP can prove his assertions is to take an uncompressed WAV and to encode it then decode it using the codecs of concern. Then the simple FC /B file1 file2 will tell him whether the codecs work indeed losslessly.

That will never work because the files will never be 100% identical. The header information created by eac3to (for example) when converting DTS-HD MA back to .WAVs doesn't look like the header info on any of the original .WAV files I have (WAV files from ProTools, captured off DA-88/HD CAM tapes or saved out of Audacity, which are all slightly different amongst themselves...). Once the header is removed, they match 100% bit-for-bit, but you have to get past that header first, which FC /B obviously won't do. The size of the header changes as well, so the FC will report nearly every byte being different.

Maybe create a wav file from an existing DTS-HD MA first (using eac3to or something), encode that wav back to DTS, and then extract it again and see of the two files from the same extraction method match... That would probably work unless there's a date/time stamp in the header or something that would always change. But if the file size is exactly the same, FC should show only a few bytes different at the head of the file...

Visual side-by-side hex editing is the best way to verify it...

[Ghitulescu]

You are probably right, I remember having this problem in the past with some audio SW that insisted to put an extra header to the wave.
And yes, FC is not able to jump over the header, but I think I met once a file compare SW that could "understand" a shift of the identical values of both files (and giving 100% match, if the audio data was 100% identical, only shifted). IIRC it was in the context of the CD-DAE offset issue.

[Midzuki]

The .WAV header is easily removed with riffstrip.exe

[tebasuna51]

There are two kinds of wav header that you can obtain with eac3to:

- The old standard header, you need add the parameter -simple

- The WAVE_FORMAT_EXTENSIBLE header (already defined in past century), default for eac3to, with ChannelMask and other extra info.

There are other soft than can add other extra chunks before and after the 'data' chunk.
Only the 'data' chunk must be compared to see audio differences.

[filler56789]

An overdue update to this thread ( or at least I think so )

http://forum.doom9.org/showthread.php?t=168133