HD-Audio to FLAC, or not?

[LeXXuz]

Up front, please bear with me if this reads more like an essay then a simple question. ;)

Well... this is bothering me for some time now. And I would love to have some input from audio experts.

Many moons ago it was almost mandatory to convert HD-Audio tracks to a much smaller and mostly lossy format. Disk space was much more expensive than today, and what's the point in compressing video for space sake if you keep audio tracks that can easily be several GB alone, right?

So encoding to DTS/AC3 (or just keeping DTS/AC3 core from HD tracks) was my prefered choice for many years. My AV back then had no HDMI inputs and couldn't handle HD-Audio anyway.

Well, a few years ago I upgrade to an HD capable AV-System.
Again, the question what to do with audio now. Since the AV receiver was now capable of Multichannel PCM, the decision was obvious to transcode HD-Audio to 16-bit FLAC from now on, instead of lossy DTS/AC3 tracks.

It seemed to be the best compromise between file size and quality.

A few month ago, merely by accident, I noticed some differences between the original HD-Audio tracks and the transcoded FLAC tracks while having a movie night with friends.

The days after I investigated even more movies and came to the conclusion that the source audio tracks kinda sound better. It's hard to describe, sometimes the dynamic sounds better, or the spatial resolution gives me more of the 'you are right in the middle' impression than with the transcoded FLAC.

Since then I keep asking myself if it is still a good idea to transcode to FLAC?

And I'm wondering if:

1) I'm just imagining things,
2) they just occur because my AV has to use different decoding algorithms for DTSHD/THD/FLAC (and I still haven't found the best matching settings obviously),

OR
3) there is any additional information inside DTS/THD tracks besides the plain audio data that gets lost during transcoding to FLAC and therefore may change the acoustic experience?

(I'm not talking about object based audio formats like Atmos/DTS:X just 'plain' DTSHD/TrueHD tracks.)

You could argue why bother, just keep the source tracks. Well, I still feel uncomfortable by keeping audio tracks that are several GB in size while spending hours on encoding video to get smaller files.

Anyhow, thank you for reading and I'm eager to read your thoughts on this. :)

[tormento]

instead of lossy DTS/AC3 tracks.
DTS is not necessarily lossy. DTS-HDMA is lossless, such as some Dolby formats. Even with lossy format you will have no benefit converting them to FLAC: shit in leads to shit out.

I noticed some differences between the original HD-Audio tracks and the transcoded FLAC tracks while having a movie night with friends.
Simply because a DTS/Dolby audio is not just "plain audio". There can be metadata, describing much more than the "plain audio" itself, to make it easy. If you are interested, read some wiki or official internet sites.

Since then I keep asking myself if it is still a good idea to transcode to FLAC?
IMHO no. When you use a file format you have to consider portability and longevity. DTS/Dolby can be streamed in original format thru HDMI or SPDIF to an A/V and offload all the decoding process to the A/V. You can use FLAC on many A/V but only as audio files, not directly decoded when part of a movie or bitstreamed to A/V.

my AV has to use different decoding algorithms for DTSHD/THD/FLAC
Are you bitstreaming or feeding PCM? 99% FLAC can't be bitstreamed.

[LeXXuz]

DTS is not necessarily lossy.
When I'm talking lossy DTS I mean DTS(-Core) not the HD formats.


Simply because a DTS/Dolby audio is not just "plain audio". There can be metadata, describing much more than the "plain audio"

That's what I meant. I know there is some additional data stored like speaker setup and such but what/how exactly can it affect the acoustic experience? Without going into too much tech detail.

IMHO no. When you use a file format you have to consider portability and longevity.

I don't care about that. My devices can decode FLAC to PCM on the fly. And I only create my files for myself and no one else. All I care about is the best ratio between fidelity and file size, unless of course some vital information is lost which I'd like to find out.

Are you bitstreaming or feeding PCM? 99% FLAC can't be bitstreamed.

Typo. I meant PCM of course. ;)

[tormento]

I don't care about that. My devices can decode FLAC to PCM on the fly. And I only create my files for myself and no one else.
The beginning of your thread was about file size is no matter to you. So, I can’t understand why you want to convert to FLAC a perfectly working DTS, if your flac doesn’t come from a previous audio processing and you want to preserve same quality.

I do convert everything to AC3 because my devices can’t accept any other format and I have some storage requirements, such as I prefer good video more than audio and I process it with FFMPEG to have audio normalization, since I live in a flat and don’t want to wake up my neighborhood at 3 am because of a unexpected explosion.

Do not forget that your devices support FLAC now but, as I told you, think about longevity in a 20-30 years time frame if you are a movie collector as I am.

[LeXXuz]

The beginning of your thread was about file size is no matter to you. So, I can’t understand why you want to convert to FLAC.

Sorry if that was misleading. File size DOES matter to me, but also fidelity. That's why I chose a lossless format like FLAC as a compromise.


Do not forget that your devices support FLAC now but, as I told you, think about longevity in a 20-30 years time frame if you are a movie collector as I am.

Who knows what's in 20 years. :rolleyes:
Looking 20 years back, that was the time before I got my first DVD-R drive. So, like most people I encoded my DVDs to AVI with 'Xvid/DivX or SVCD and split those onto several CDs. You know where these copies are today? In the garbage. All of them. They have been replaced by much better versions in the meantime.

So in many years from now, disk space may be so damn cheap that I can remux my vast movie collection on my NAS and don't care about re-encoding at all. ;)

But until then I'd like to have the best compromise. :)

[mbcd]

But what is stored in Metadarta that makes it sound that much better?

There is still a dialnorm and may be some "Room-type" ... but I dont think that it improves that much, because its all about filtering and filters cant change the sound that much heavily.

May be the loudness downmix or playback of the channels are stored in the dts stream, but then its all about leveling when encoded to flac.

I mean: Metadata cant improove quality that much, or am I wrong? The basicstream is both the same ... but there are still some filter only available on DTS-Playback.

[Boulder]

I think audio enthusiasts prefer direct output anyway, i.e. without any dynamic compression or filtering in the decoder part.

I've never tested decoding a DTS-HD MA track to WAV and comparing it to the WAV track resulting from a FLAC file which was encoded from the DTS-HD MA track. It should be bit identical by nature.

[LeXXuz]

I mean: Metadata cant improove quality that much, or am I wrong? The basicstream is both the same ... but there are still some filter only available on DTS-Playback.

That's what I was thinking all the time. Even the downgrade from 24 to 16 bits should not be noticeable on a consumer device. If you need the track for further processing that's a total different story.

It's not really a loss in quality I've noticed. It's more like the sound stage is shifting to a more upfront position for example. Or the center channel being louder or quiter than in the original track and so on.

Anyway, I'm talking nuances here. My wife for example can't hear any difference at all. :D

I think audio enthusiasts prefer direct output anyway, i.e. without any dynamic compression or filtering in the decoder part.

Yes. Usually I use direct output on my Yamaha AVR. Unless it's in the middle of the night when I let it enhance dialogue level and reduce overall dynamic range.


I've never tested decoding a DTS-HD MA track to WAV and comparing it to the WAV track resulting from a FLAC file which was encoded from the DTS-HD MA track. It should be bit identical by nature.

From what I've read it should. And I read quite a lot before I decided to use FLAC a couple of years ago. Because I was under the impression I can't go wrong with FLAC. I still have a high fidelity lossless track which is always smaller than DTSHD/TrueHD, escpecially when going from 24 to 16bit.

So, that's why I started this topic. Because I simply can't explain myself why I hear these tiny differences.

That's why I was hoping for someone with a lot of knowledge about HD Audio to put my mind at ease. ;)
And either tell me my AVR is just messing with me, or there is indeed some additional data in these tracks that can cause AVR's to produce a slightly different sound characteristic.

[tebasuna51]

The audio data stored in a DTS-MA is bit-identical to the recoded FLAC.

Other question is how you can config your Audio Receiver to play one stream or other.

With the same configuration in your receiver you can't difference both.

Also you need a good audio equipment (receiver and speakers, much more than 1000 €) and good ears (golden ears) to difference a DTS-MA from a AC3 640 Kb/s

[tormento]

To decode DTS to FLAC you need a library, perhaps that one is not the best in the world and the library used on the device to decode DTS is better than the one on your PC.

What do you use to decode DTS and encode in FLAC?

If the answer is eac3to, much better you switch to FFMPEG.

[tebasuna51]

The libdcadec with eac3to to decode DTS-HD is the same included in ffmpeg (improved in ffmpeg to decode DTS-Express).

The output is bitidentical than the sources used to encode the DTS-MA (tested by me, and better until last bit than ArcSoft decoder with some rounding error).

[SeeMoreDigital]

Speaking as somebody who likes listening to surround sound music, I used to re-encode every audio disc format (ie: Lossy DTS and Dolby Digital. Along with lossless DTS-HD MA, Dolby TrueHD and PCM) to FLAC.

Nowadays however, I only re-encode lossless PCM audio to FLAC. All the other audio formats I keep "as is". And place them within the .mka container.

And when it comes movie audio formats, I don't bother re-encoding them, I keep those "as is" too ;)

[tormento]

The libdcadec with eac3to to decode DTS-HD is the same included in ffmpeg
Do spectrogram and bit to bit comparison of eac3to and new FFMPEG decoded material.

eac3to libraries are far obsolete.

[tebasuna51]

Do spectrogram and bit to bit comparison of eac3to and new FFMPEG decoded material.

eac3to libraries are far obsolete.

If I compare the eac3to decode and the ffmpeg decode and is different I must conclude than there are a regression in ffmpeg, because the eac3to decode is bitexact with source used to encode the DTD-MA.

The ffmpeg can decode DTS-Express and maybe manage better some errors, but can't improve a bitexact decode.

...to transcode HD-Audio to 16-bit FLAC

After re-read the first post I see your FLAC encode is only 16-bits, if the source is 24 bits you can listen a difference because the average human ear can difference until a precission of 20 bits

[Boulder]

After re-read the first post I see your FLAC encode is only 16-bits, if the source is 24 bits you can listen a difference because the average human ear can difference until a precission of 20 bits

I'd still say ABX'ing that difference would require a lot of effort - something that won't be possible while watching a movie.

[tormento]

the eac3to decode is bitexact with source used to encode the DTD-MA.
Need more information about this, considering eac3to AFAIK uses old FFMPEG avcodec-54.dll to decode DTS...

[tebasuna51]

Need more information about this, considering eac3to AFAIK uses old FFMPEG avcodec-54.dll to decode DTS...

You are wrong, to decode DTS eac3to v3.34 uses libdcadec.dll

v3.30
* libDcaDec is now default for all DTS tracks except XSA / low bitrate

[tebasuna51]

I'd still say ABX'ing that difference would require a lot of effort - something that won't be possible while watching a movie.

Yes, of course my old ears can't listen the difference, but at least is possible in some circunstances.

[tormento]

to decode DTS eac3to v3.34 uses libdcadec.dll
Last commit 2 Jun 2016.

Please elaborate your theory of perfect decoding to source quality.

[tebasuna51]

Please elaborate your theory of perfect decoding to source quality.

Is not difficult to understand:

1) I make some wav (24 int 48000 samplerate) files sources

2) I encode that sources to DTS-MA's

3) Decode the DTS-MA's with eac3to libdcadec

4) Compare the output with sources, for instance with

FC /B source1.wav decoded1.wav

and they are bitexact.

[tormento]

Is not difficult to understand:

1) I make some wav (24 int 48000 samplerate) files sources

2) I encode that sources to DTS-MA's

3) Decode the DTS-MA's with eac3to libdcadec

4) Compare the output with sources, for instance with

FC /B source1.wav decoded1.wav

and they are bitexact.


2) Which encoder?
3) DTS-HDMA is lossless. You are telling me that other decoders lose bits around?

[tebasuna51]

2) Which encoder?
3) DTS-HDMA is lossless. You are telling me that other decoders lose bits around?

2) DTS HD Master Audio Suite

3) I say than libdcadec don't lose bits.
Some version of ArcSoft decoder lose some last bit, only a few, seems a rounding problem.

[tormento]

2) DTS HD Master Audio Suite

3) I say than libdcadec don't lose bits.
Some version of ArcSoft decoder lose some last bit, only a few, seems a rounding problem.


We were talking about FFMPEG, right?

[tebasuna51]

ArcSoft was the decoder, not free, used by eac3to for DTS-HD before libdcadec.

ffmpeg uses the same libdcadec improved to decode DTS-Express and maybe to manage better some errors, then is bitexact also.

[tormento]

ffmpeg uses the same libdcadec improved to decode DTS-Express and maybe to manage better some errors, then is bitexact also.
That's the exact reason of my change to FFMPEG.

[LeXXuz]

Sorry, I wasn't at home for the last couple of days. I followed this thread but didn't answer as I hate to type on these tiny mobile devices. :angry:

Let me recap a few things to see if I understand you guys correctly.

IN GENERAL:
- FLAC's audio data is in general bit-exact to DTSHD/TrueHD's audio data.
- DTSHD/TrueHD tracks have metadata which can have an impact on the decoders acoustic display. However this data is discarded when the AVR is set to a straight decode. Then the acoustic display should not be distinguishable between FLAC/PCM/DTSHD/TrueHD.
- 16-bit vs 24-bit seems to be a highly arguable topic. I read many articles on the net which convinced me to stick to 16-bit.
- Human hearing might be able to notice differences in resolution up to 20-bit. However, my problem doesn't seem to be bit-depth related as I've heard differences even if the source track was 16-bit as well.

DECODERS:
- I've used eac3to with Arcsoft's DTS decoder until a couple of years ago people mentioned that it is not bit-exact. So I switched to eac3to's libdcadec until now.
- eac3to's libdcadec always puts out the "XLL output not lossless" warning which I don't quite understand. Although according to many posts here in the forums this warning can be safely ignored(?)
- nowadays ffmpeg is suggested to be a better decoding/encoding solution, although (following the discussion between tebasuna51 and tormento) it is arguable IF the output is any different from eac3to's output at all.

(My) Conclusion:
In general FLAC tracks should produce the same acoustic display if certain steps are taken into account. The decoding process should be bit-exact and the AVR decoder should be set to a straight decode, bypassing any specialised decoding routines for Dolby/DTS.

As I don't have the money for a commercial HD-Audio encoder (using either Dolby or DTS), I decided to stay with FLAC. In 16-bit it delivers a much better ratio between file size and fidelity (for me!) than the source tracks from Blu-ray.

The differences I've heard are either related to eac3to's decoding/transcoding process or to me being stupid and imagining things. :o:D

ffmpeg is a well maintained project, while eac3to hasn't seen any updates in years. So I've decided to switch to ffmpeg for encoding my audio from now on.

I've created this batchfile:
ffmpeg -i "%~f1" -af aformat=s16:48000 -compression_level 12 -stats "%~dp1%~n1_16bit.flac"

I'm not very familiar with ffmpeg so I would appreciate any comment if I may have missed any important switches/settings or not.

[tebasuna51]

Is a good option, for my ears 16 bits is also enough.

And I also use ffmpeg to recode when I need play a movie in a device without support for DTS-MA/TrueHD, most the time I need recode to AC3.

Of course ffmpeg do the bitexact decode like libdcadec, and without warnings like: "XLL output not lossless"

Just for clarify, from DTS-HD papers:
XLL Extension for Lossless Audio coding, a bit-for-bit recreation of the original master recording using variable bit rate encoding as high as 24.5 Mbps for Blu-ray Disc and 18.0 Mbps for HD DVD formats

A DTS-HD bitstream is composed by standard DTS frames (the core) plus some extensions, for lossless encode (XLL for MA), for additional channels (XXCH), for high bitrate (XBR), high samplerate (X96), ...

But not all frames need a XLL extension because the 'core' is enough, for instance to encode silence, then the libdcadec warning is unnecesary, like I say ffmpeg suppress that warning from old libdcadec (not error).

[Richard1485]

Yes, and eac3to does not use a special version of libdcadec (https://forum.doom9.org/showthread.php?p=1749081#post1749081), so you can copy this more-up-to-date version (https://github.com/foo86/dcadec/releases/download/v0.2.0/dcadec-0.2.0-win32.zip) over the dll that comes with eac3to and never have to see that annoying warning. In fact, I wish that the eac3to on videohelp could be packaged with the updated dll, so that we don't we have deal with so many questions about this warning.

[tormento]

Yes, and eac3to does not use a special version of libdcadec (https://forum.doom9.org/showthread.php?p=1749081#post1749081), so you can copy this more-up-to-date version (https://github.com/foo86/dcadec/releases/download/v0.2.0/dcadec-0.2.0-win32.zip)
Already posted here (https://forum.doom9.org/showthread.php?p=1801227#post1801227).

dcacdec 0.2.0 is from 2016.

[Richard1485]

Already posted here.

Yes, but you didn't quote the part of my post that related to the XLL warning, which is what I was talking about.

dcacdec 0.2.0 is from 2016.

I know, but it's still more up to date than the one in eac3to. It's a shame that the development of libdcadec now takes place only within ffmpeg, because it would be nice to have an update that would enable eac3to handle DTS Express.