eac3to - audio conversion tool

[ndjamena]

Well, obviously I have no idea how audio works.

The wav files are little endian and as far as I can tell it is the most significant bits that are missing (the first byte of three).

The first byte of each group of 3 (24 bits) is zero, if the "endian" is "little" then that would make the first byte the "big" one... and that's what's missing...

Are the samples stored backwards for some reason?

Is it actually the LEAST significant bits that are missing?

That would solve everything.

-edit- oh, so either most significant doesn't mean biggest it means first, or "end" means "start"... or something...

From wikipedia:

For example, the number 123, has the hundreds-digit, 1, left-most which is understood by a numerate reader. This is an example of a big-endian convention taken from daily life.

-so little endian would store the byte that contains the smaller value first and downsampling would pretty much just remove that byte.

-edit2- Little Endian = LITTLE END FIRST

[nevcairiel]

The endianess makes no difference at all. Its just something for eac3to to handle, not for you to ever think about.

[ndjamena]

I was looking at the WAV file with a hex editor to see what was going on.

Basically:

16 bit audio: 12
24 bit audio: 123
16 bit in 24 bit: 120
24 bit converted to 16 bit: 12
16 bit in 24 bit converted to 16 bit: 12


In case anyone else was confused as to how 16 bit in 24 bit audio was configured. The extra zeros are added to the small end of the sample, not the big end, effectively multiplying the value by 256. It's the equivalent of adding an extra zero to 12 to make 120 and alters the magnitude of the scale while keeping the same difference between the original sample points. 12 to 11 is the same as 120 to 110 but altering the zero gives you room to add precision which would give you the equivalent of true 24 bit audio.

That's why the volume stays the same between simply stripping the zeros and doing a proper resampling.

Stripping zeros is still better than resampling since resampling isn't lossless (with an even number of outcomes there's no middle point in whole byte numbers, it SHOULD be zero but then there will always be one more negative number than positive, so they simply don't scale well, silence (0s) winds up getting speckled with random noise(-1s)).

At least one person reading this thread didn't know that, and no one seemed willing to point it out.

[tebasuna51]

@ndjamena
I read your discussion without understand what you want do.

1) Save space downsampling DTS-MA 24 to 16 bits in m2ts's?

a) If the main movie is a real 24 bits you lose precission, not volume.
b) If is real 16 bits and only credits have real 24 bits you can save only a few space.
c) If is a fake 24 bits (16 bits + 8 0's) you can save space without lose precission or volume.
d) If is 20 bits you lose less precission downsampling to 16 bits, but 20 bits is not a standard format and can't be used.

2) Save space when recode to a lossless format like FLAC?

Then in cases b) or c) is recommended, and safe, use -down16
In cases a) or c) you lose precission using -down16

3) About endianess.
You must trust in proper soft, like eac3to, than manage endianess without problems.
Only the less significant byte is deleted with -down16 and the volume remain the same.

When output .WAV and .W64 are always little endian samples.
And when output .PCM are always big endian samples. (not recommended use this format because is without header)
EDIT: Also when output multichannel .PCM the channel order is not the same than WAV or W64

[ndjamena]

I ran out of hard drive space and discovered what a PITA trying to watch from the disc was, so I'm re-ripping, removing all the extra audio tracks and down sampling the main lossless tracks to 16 bit FLAC until I can afford a rack mount.

I saved 20GB just converting the audio to 16 bit FLAC on the X-Men movies alone so I figure I'm on the right track here.

(My WDTV SMP won't play 24 bit FLAC from an MKV without glitching, I had been converting to full bitdepth FLAC AND keeping the original track as well, plus all the commentary/audio description tracks and whatnot... so there's plenty of reasons to go down this track for now.)

I didn't know how 16 bits in 24 bits worked, from the simple way it's described I assumed it just used smaller numbers that would easily fit in a 16 bit integer, apparently Dark Space thought the same thing. But the numbers are the same size, it's just that the less significant 8 bits are empty, which is where the extra precision between 24 and 16 bit comes from, which leaves them pretty much exactly the same as 16 bit audio when those 8 bits are removed.

Should I have known that from the getgo?

[ndjamena]

When I used -down16 -dontdither on Terminator Salvation it destroyed the audio in the true 16 bit segments.

I'm thinking that's a bug, although I don't suppose I'm supposed to be using the -dontdither switch at all.

What would it have done? If it dithered the 16 bit up to 24 bit and then didn't dither it back to 16 bit it still should have turned out fine... no?

Would it have added zeros to the big end of the 16 bit section when up sampling and then taken the little end away when down sampling?

I should probably test it but I've deleted the blu ray structure and would have to rip it again.

-Edit- When using -down16 on silent PCM without -dontdither at least a sixth of the zeros are changed into either 1s or negative 1s.

[gabbett1]

try this then: http://forum.doom9.org/newreply.php?do=newreply&p=1742199

remux the .m2ts file witj tsmuxer before trying to demux or anyhow process the atmos stream.

I'm confused. The link just puts me to reply to this forum.

[LigH]

^ I guess he caught a wrong URL in his clipboard; Ctrl+C is sometimes unreliable. It's probably this post (http://forum.doom9.org/showthread.php?p=1742199#post1742199) (plus some previous and following). Apparently Transport Streams are not as trivial and unambiguous as one may expect.

[Thunderbolt8]

yes, sorry. wrong ctrl+c

[ndjamena]

OK, so when appending an m2ts file with 16 bit DTS-MA to an m2ts file with 24 bit DTS-MA using eac3to even without using any switches, the 16 bit segment will be reduced to silence. All the higher order bits will be set to either FFF or 000 and the rest is pretty much nothing but noise. Extracting the 16 bit segment by itself produces perfect output. The fact that it doesn't issue an error or even a warning seems to indicate that that's actually a bug.

And when down sampling to 16 bit eac3to DOESN'T try to squeeze the number from a scale of 16777215 to a scale of 65535, it just removes the lower eight bits, then applies "dithering" which is basically just random noise to hide the artificial "colouring" of the sound any down sampling method must create. It applies the dithering even if what it's processing is nothing but perfect silence. The -dontdither switch supresses the application of any dithering.

[LigH]

A good dither algorithm is not necessarily random, it may even be better. If the original values with higher precision are known, then they can be used to calculate lower precision values with a medium "virtual precision" by distributing the error across neighbor values, so that the weighted average of neighbor samples approaches the former more precise value better. From image processing you may know ordered dither patterns (Bayer) or error propagation noise (Floyd-Steinberg etc.); audio dithering can work in a similar way. Properly implemented (in relation to "noise shaping"), it can do miracles in low volume scenes. I do not know, though, how eac3to works in this regard...

[nevcairiel]

And when down sampling to 16 bit eac3to DOESN'T try to squeeze the number from a scale of 16777215 to a scale of 65535, it just removes the lower eight bits, then applies "dithering" which is basically just random noise to hide the artificial "colouring" of the sound any down sampling method must create It applies the dithering even if what it's processing is nothing but perfect silence. The -dontdither switch supresses the application of any dithering.

That is the correct way to do this. Anything else would not result in the expected audio. And you should never disable dithering.

A good dither algorithm is not necessarily random, it may even be better.

Audio Dithering is generally always based on randomness, so you can guarantee no unwanted harmonic interference piles up somewhere.
Even "Noise Shaping" uses randomness at its base, its just transformed slightly to move the random noise into desired frequency regions.

[Motenai Yoda]

And when down sampling to 16 bit eac3to DOESN'T try to squeeze the number from a scale of 16777215 to a scale of 65535, it just removes the lower eight bits

It's the same thing, divide by 256 then truncate (if you don't work in int), give you bit identical result than just a 8bit shift to right.

[Thunderbolt8]

is the dcadec decoder able to decode DTS:X streams?

[Smithy]

2015 DTS Blu-Ray Demo Disc Vol.19

Decode Divergent DTS:X without errors.

MKV, 1 video track, 1 audio track, 0:02:01, 24p /1.001
1: h264/AVC, English, 1080p24 /1.001 (16:9)
2: DTS Master Audio, English, 7.1 channels, 24 bits, 48kHz
(core: DTS, 5.1 channels, 1509kbps, 48kHz)
[a02] dts, 48000, 7.1
[a02] Extracting audio track number 2...
[a02] Decoding with libDcaDec DTS Decoder...
[a02] Writing WAV...
[a02] Creating file "V:\DTSX Demo - Divergent.wav"...
[a02] The original audio track has a constant bit depth of 24 bits.
Video track 1 contains 2904 frames.
eac3to processing took 14 seconds.
Done.

[Thunderbolt8]

but can we be sure that everything in it has been decoded and used correctly? how does DTS:X work, is it some extension like atmos for TrueHD? maybe then just the "core" DTS-HD MA track was used and not the DTS:X extension?

[Smithy]

sound is fine.
the core is 5.1 not 7.1 ;)

[Thunderbolt8]

sound is fine.
the core is 5.1 not 7.1 ;)I dont mean the DTS core inside the DTS-HD MA track, but something like possibly a DTS-HD MA core inside the DTS:X track. or a DTS:X extension which could be stripped or dropped and perhaps we wouldnt know of it.

[Thunderbolt8]

sound is fine.
the core is 5.1 not 7.1 ;)I mean not the DTS core inside the DTS-HD MA track, but something like possibly DTS-HD MA core inside the DTS:X track. or DTS:X extension which could be stripped or dropped and perhaps we wouldnt know. so eac3to could either recognize only this known "DTS-HD MA" core inside the full DTS:X track or not recognize the DTS:X extension of the full track (in case it works like an extension) and therefore disregards the part it doesnt know.

dcadec was last modified 5 months ago on github, not sure how many DTS:X test samples have already been available back then to help with the implementation.

[Smithy]

yes, this part is doesn't know

but dts-hd ma is the core Track of DTS:X for backward Compatibility like THD (Atmos) or PCM (Auro3D)

and DTS:X is more Special vs. THD ATMOS, maybe its possible to decode DTS:X

[gabbett1]

^ I guess he caught a wrong URL in his clipboard; Ctrl+C is sometimes unreliable. It's probably this post (http://forum.doom9.org/showthread.php?p=1742199#post1742199) (plus some previous and following). Apparently Transport Streams are not as trivial and unambiguous as one may expect.

All that link does is take me back to the top of that page.

[madshi]

eac3to v3.30 released

http://madshi.net/eac3to.zip

* libDcaDec is now default for all DTS tracks except XSA / low bitrate
* fixed: #310: Use ffmpeg like external encoder
* fixed: #312: Convert to wav with a big negative delay works incorrectly
* fixed: #314: 'edit' option adds one frame less than expected
* fixed: #345: Fails to decode Atmos track with no embedded AC3 track

[SeeMoreDigital]

Thanks madshi :)

[ron spencer]

fixed #345 is sweet!!

for:

libDcaDec is now default for all DTS tracks except XSA / low bitrate


Does this mean the Arcsoft decoder is not longer needed?

[tebasuna51]

Thanks madshi!

Does this mean the Arcsoft decoder is not longer needed?

Only for DTS-Express:

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

[Sparktank]

Good news, everybody!

Thanks for the update. :)

[r0lZ]

Thanks for the update, but I'm just too late to report that libDcaDec may have a bug. It fails to decode some DTS HD MA tracks extracted from BDs, with the message "Synchronisation error". However, as far as I can tell, there is no sync error, the track seems perfect, I can't hear any glitch, the DTS core can be extracted without problem and the other decoders (Libav and Arcsoft) work fine. I have had that problem already 3 times, so it seems that it's not a minor problem. I have a DTSHDMA track causing the problem but unfortunately it is way too big (2.7 GB) to be uploaded somewhere, and the sync error happen near the end. Can I simply cut it at any position and upload the end of the file? I guess that will not work. Right?

Also, madshi, please reopen this bug: Failure to demux subtitle tracks from SSIF or MPLS of a 3D-BD (http://bugs.madshi.net/view.php?id=87)
I have never received the notifications for the message with your request for a sample. I can't provide a sample if I don't know that it is needed.

[Boulder]

You might want to report the libdcadec problem here: https://github.com/foo86/dcadec/issues . I see no reason why the sync error wouldn't occur after cutting the file.

[madshi]

Thanks for the update, but I'm just too late to report that libDcaDec may have a bug. It fails to decode some DTS HD MA tracks extracted from BDs, with the message "Synchronisation error". However, as far as I can tell, there is no sync error, the track seems perfect, I can't hear any glitch, the DTS core can be extracted without problem and the other decoders (Libav and Arcsoft) work fine. I have had that problem already 3 times, so it seems that it's not a minor problem. I have a DTSHDMA track causing the problem but unfortunately it is way too big (2.7 GB) to be uploaded somewhere, and the sync error happen near the end. Can I simply cut it at any position and upload the end of the file? I guess that will not work. Right?
You can use a negative delay value in eac3to to remove the start of the track. Samples are important for problems like this. But I can't personally fix them, so you need to report such bugs to the dcaDec developer:

https://github.com/foo86/dcadec

Also, madshi, please reopen this bug: Failure to demux subtitle tracks from SSIF or MPLS of a 3D-BD (http://bugs.madshi.net/view.php?id=87)
I have never received the notifications for the message with your request for a sample. I can't provide a sample if I don't know that it is needed.
You can reopen the bug yourself, you don't need me to do that. I've already given all users the right to reopen bugs.

[r0lZ]

OK, thanks.

I have already reported the problem on the dcadec bug tracker here (https://github.com/foo86/dcadec/issues/38#issuecomment-153026239), with this sample (http://download.videohelp.com/r0lZ/tmp/DTS_HD_MAsync_bug_sample.dts), and they have replied this:

FWIW, the libdcadec wrapper in FFmpeg does not encounter any error - which indicates that the dcadec decoder is working fine, and the problem may be in reading/parsing the file.

So, it seems that the error is not related to the dcadec decoder, and may be caused by eac3to or something else. Any thoughts?

I will re-open the demux SSIF bug, but I have to create a sample first...

[r0lZ]

Madshi, I have seen your reply in the dcadec bug tracker. Thanks.

To facilitate the decoding (at least while the origin of the "bug" is unclear), is it possible to turn off the DCADEC_FLAG_STRICT via eac3to's command line ? How ? Or is it only a flag that can be changed at compile time ?

If it's not possible, can you consider turning it off in a forthcoming version?

[madshi]

Please add an issue to the bug tracker to request an option to turn the strict decoding mode off, so that I don't forget it. It can currently only be changed in eac3to by recompiling.

[tebasuna51]

I don't know if that's help:

Decoding the sample with a recent ffmpeg, finish without errors, but using ffmpeg version N-71329-g235589e 07-Apr-2015 finish with:

libdcadec/exss_parser.c+395: Invalid EXSS size0kbits/s

The output for both versions are bit-identical.

Maybe you can output a <WARNING> but continue the decode.

[madshi]

I think at this point in time it's better to fail, because if dcadec sees a reason for a warning, this could still be a bug in dcadec (or a damaged audio file). It's better to force the user to double check, and maybe use ArcSoft instead, than to risk just writing a warning to the log which the user might simply not see, and then eventually produce a faulty audio file. After a couple more months or years, when we're more certain about dcadec being "bug free" or not, we can think about posting warnings and continuing decoding then. At least that's my opinion. Anyone having a different opinion?

[Boulder]

I propose a parameter to disregard the error, just because dcadec is the only freeware solution to decoding such files :)

[AYColumbia]

Thanks for the update madshi.

[jpsdr]

Thanks for the update madshi.
And, it's just to know what the actual statut is, do you also have update ffmpeg/flac with more recent version, or still haven't time ?

[r0lZ]

I think at this point in time it's better to fail, because if dcadec sees a reason for a warning, this could still be a bug in dcadec (or a damaged audio file). It's better to force the user to double check, and maybe use ArcSoft instead, than to risk just writing a warning to the log which the user might simply not see, and then eventually produce a faulty audio file. After a couple more months or years, when we're more certain about dcadec being "bug free" or not, we can think about posting warnings and continuing decoding then. At least that's my opinion. Anyone having a different opinion?
Well, currently, only eac3to is unable to decode that picky DTSHDMA tracks. Even ffmpeg doesn't turn the strict decoding on, and has therefore no problem.

I agree that turning off the strict decoding mode is dangerous, but IMO, the "synchronisation error" reported (most probably erroneously) by DcaDec should be ignored. I don't know if it is possible to continue anyway after that error (and only that one), but if it's feasible, that could be a very good thing.

I have requested an option to turn the strict mode off via your bug tracker (here (http://bugs.madshi.net/view.php?id=358)), but honestly, I would prefer to leave that flag on, but have a workaround for what seems to be a bug in the DTS decoder. After having double-checked the original DTSHDMA and the conversions with other decoders, it seems that the streams are perfectly normal. Therefore, DcaDec with the strict option on is at least way too picky, at least for this specific error.

Also, note that some decoders do NOT stop after an extremely great number of synchronisation errors. It's the case when demuxing subtitles from some 3DBD (as reported in another bug on your tracker (http://bugs.madshi.net/view.php?id=87)). I see no reason to be much more tolerant with the subtitles than with the DTS tracks.

Anyway, a solution is necessary, but I'll be happy with just an option to turn the strict mode off, although I think it's not the best solution.

[73ChargerFan]

I have a DTSHDMA track causing the problem but unfortunately it is way too big (2.7 GB) to be uploaded

It'd be really useful to get that file to the developers if there really is a problem (i.e., it isn't just a bad rip or BD decode.)

That large of a file can be easily transferred between two computers both using utorrent, see How to Share Personal or Public Files Using uTorrent. (http://www.wikihow.com/Share-Personal-or-Public-Files-Using-uTorrent) It would be a private pseudo tracker run from your computer, and won't be publicly shared.

Or see the NetworkWorld article 19 free cloud storage options (http://www.networkworld.com/article/2932962/cloud-storage/19-free-cloud-storage-options.html).

[r0lZ]

I have already isolated the part causing the problem and posted it here (http://download.videohelp.com/r0lZ/tmp/DTS_HD_MAsync_bug_sample.dts). (See post #13582 (http://forum.doom9.org/showthread.php?p=1745182#post1745182).) In this case, there is no need to analyse the entire track. But thanks for the hints about transferring large files. I didn't know that "pseudo tracker" possibility of uTorrent. (BTW, I like also Infinit (https://infinit.io/) to share large files, but it requires to install a little program on your computer.)

[ndjamena]

OK, so I think I've fixed MediaInfo's issues with FLAC default layouts. I've also added "VALID_BITS" as a recognised tag and have moved it to the audio stream as "Valid bits".

I've removed HDCD if the value is zero... otherwise I've called it "High Definition Compatible Digital" and set it to "Yes"... Is that OK? Is it important to know if it's specifically tagged as NOT HDCD?

Is there anything else I should attempt to prepare MediaInfo to encounter?

[madshi]

OK, so I think I've fixed MediaInfo's issues with FLAC default layouts. I've also added "VALID_BITS" as a recognised tag and have moved it to the audio stream as "Valid bits".

I've removed HDCD if the value is zero... otherwise I've called it "High Definition Compatible Digital" and set it to "Yes"... Is that OK? Is it important to know if it's specifically tagged as NOT HDCD?

Is there anything else I should attempt to prepare MediaInfo to encounter?
Sounds good to me! FWIW, it might make sense to only list "valid bits" if it's less than the designated FLAC bitdepth. E.g. one common case is having 20bit in a 24bit container because FLAC doesn't support encoding a 20bit bitdepth, IIRC. I'd also ignore a 0 value for valid bits. Shouldn't occur in real life, but in theory it could be there for e.g. an audio track which has nothing but silence (zeroes) in it. I'm not a native english speaker btw, so maybe someone has a better idea how to name this in clear text? Not sure if "valid bits" is a good name.

I'd suggest to use "HDCD" as the name because that's the term everybody is familiar with. Writing "High Definition Compatible Digital" is like naming DVD "Digital Versatile Disc". Users would look at that three times and wonder what it means while "HDCD" is easy to recognize for anybody who knows what it is. eac3to always checks all audio tracks for HDCD, so if you find "HDCD" in the metadata, having it set to 0 usually means the track is *not* HDCD. But if you want to be extra safe that you're not reporting anything wrong then just reporting HDCD if it's set to "1" is fine, too.

IIRC, support for the "WAVEFORMATEXTENSIBLE_CHANNEL_MASK" is already available, right? At some point there was a problem with supporting "=0X" vs "=0x". Maybe you could double check that both is supported (you should simply ignore the case).

Thanks!

[Music Fan]

I read something astonishing about HDCD ;
http://forum.doom9.org/showthread.php?p=1612018#post1612018
HDCD can not be saved in .wav because sub channel will be lost.

Is it true ?

[ndjamena]

Sounds good to me! FWIW, it might make sense to only list "valid bits" if it's less than the designated FLAC bitdepth. E.g. one common case is having 20bit in a 24bit container because FLAC doesn't support encoding a 20bit bitdepth, IIRC. I'd also ignore a 0 value for valid bits. Shouldn't occur in real life, but in theory it could be there for e.g. an audio track which has nothing but silence (zeroes) in it. I'm not a native english speaker btw, so maybe someone has a better idea how to name this in clear text? Not sure if "valid bits" is a good name.

I'd suggest to use "HDCD" as the name because that's the term everybody is familiar with. Writing "High Definition Compatible Digital" is like naming DVD "Digital Versatile Disc". Users would look at that three times and wonder what it means while "HDCD" is easy to recognize for anybody who knows what it is. eac3to always checks all audio tracks for HDCD, so if you find "HDCD" in the metadata, having it set to 0 usually means the track is *not* HDCD. But if you want to be extra safe that you're not reporting anything wrong then just reporting HDCD if it's set to "1" is fine, too.

IIRC, support for the "WAVEFORMATEXTENSIBLE_CHANNEL_MASK" is already available, right? At some point there was a problem with supporting "=0X" vs "=0x". Maybe you could double check that both is supported (you should simply ignore the case).

Thanks!

Actually, if I point mediainfo at a flac file before it's finish it DOES say '00" valid bits...

HDCD... What about the people who don't know what it is? I didn't and had no idea why that tag was in all my encodes. That's why I thought it would be a good idea the give the full name.

Jerome has already accepted the code, so I'd either have to issue another pull request to change things or pass on what you've said here.

[madshi]

Actually, if I point mediainfo at a flac file before it's finish it DOES say '00" valid bits...
True, that's because eac3to only knows the final value after processing has run through. One more reason to ignore a value of 00... :p

HDCD... What about the people who don't know what it is?
Well, that's like saying that some people don't know what FLAC is, so you write "Free Lossless Audio Codec" instead of FLAC everywhere. But if you do that, most people who *DO* know what FLAC is will be confused, because although they know FLAC they might not know what the acronym stands for.

Just my 2 cents, of course. It's not really important to me. Just wanted to provide some feedback.

[Zenitram]

Sounds good to me! FWIW, it might make sense to only list "valid bits" if it's less than the designated FLAC bitdepth. E.g. one common case is having 20bit in a 24bit container because FLAC doesn't support encoding a 20bit bitdepth, IIRC. I'd also ignore a 0 value for valid bits.

Done (https://github.com/MediaArea/MediaInfoLib/commit/b117425dbaeefd513e5af58428731b3c9f4fa4b9).

Shouldn't occur in real life, but in theory it could be there for e.g. an audio track which has nothing but silence (zeroes) in it.

Hum... Not a good example. I hoped that this is not the implementation.
Silence with 16 valid bits is not same than silence with 24 valid bits, and this is not 0 bit of something (whatever is the name). So the value is expected to be the count of bits really used during quantization (https://en.wikipedia.org/wiki/Quantization_%28signal_processing%29) else this is only a 0 measurement (not useful).
Said another way, silence quantized at 20 bits then stored in the file as 24-bit should still have 20 valid bits in the metadata (this is the count of bits used by the digitilization tool), not 0. having only zeroes in the lowest bit does not mean that the bit is not valid (99.99999% chances it is, but in theory it is not), it may be valid (no luck, the source is with zeroes...).

True, that's because eac3to only knows the final value after processing has run through. One more reason to ignore a value of 00... :p

eac3to should know the bit depth of the input, scanning the lower bits of the full stream would be only a fallback if the input is known to provide invalid metadata (e.g. 24-bit FLAC which can be 20 or 24-bit in reality if I understand well). I understand the reason you prefer to scan the full file for checking lower bits but it may be misleading (e.g. in mathematics, 0.0000 means that it is between -0.00005 and 0.00004, it does not mean it is 0.000 or 0.00 or 0.0 or 0, which are true information but you lost the piece of information about precision).

I'm not a native english speaker btw, so maybe someone has a better idea how to name this in clear text? Not sure if "valid bits" is a good name.

SMPTE (https://en.wikipedia.org/wiki/Society_of_Motion_Picture_and_Television_Engineers) uses "Quantization bits" for this purpose in MXF (https://en.wikipedia.org/wiki/Material_Exchange_Format) file format.

In MediaInfo, I use "Bit depth" for the real value (your "valid bits") and "Stored bit depth" for the bit size in the file.

I'd suggest to use "HDCD" as the name because that's the term everybody is familiar with. Writing "High Definition Compatible Digital" is like naming DVD "Digital Versatile Disc".

I agree. Changed (https://github.com/MediaArea/MediaInfoLib/commit/1bb7de3a6ff9c1c822f0accca86cb4288381dc71).

HDCD... What about the people who don't know what it is? I didn't and had no idea why that tag was in all my encodes. That's why I thought it would be a good idea the give the full name.

As for FLAC or DVD, people put HDCD in Google and the first link is the Wikipedia page about "High Definition Compatible Digital".
Actually the acronym is more known by people able to help someone than the definition of the acronym.

IIRC, support for the "WAVEFORMATEXTENSIBLE_CHANNEL_MASK" is already available, right? At some point there was a problem with supporting "=0X" vs "=0x". Maybe you could double check that both is supported (you should simply ignore the case)

I don't remember exactly the previous behavior but ndjamena definitely fixed an issue with MediaInfo previous behavior, I have now more files with channels position. So I take his patch!

[nevcairiel]

Hum... Not a good example. I hoped that this is not the implementation.
Silence with 16 valid bits is not same than silence with 24 valid bits, and this is not 0 bit of something (whatever is the name). So the value is expected to be the count of bits really used during quantization (https://en.wikipedia.org/wiki/Quantization_%28signal_processing%29) else this is only a 0 measurement (not useful).
Said another way, silence quantized at 20 bits then stored in the file as 24-bit should still have 20 valid bits in the metadata (this is the count of bits used by the digitilization tool), not 0. having only zeroes in the lowest bit does not mean that the bit is not valid (99.99999% chances it is, but in theory it is not), it may be valid (no luck, the source is with zeroes...).

If you take a 20-bit signal, and you want to store it in a 24-bit format, what do you do? You pad it with zeroes.
Thats how its done everywhere, so you have no idea what the original bitdepth was when you get all zeroes, all the time.

Thats just a very common use-case when dealing with PCM, and eac3to wants to know if a signal was mastered wrong - since it occasionally happens that a 16-bit signal gets erroneously padded to 24-bit and encoded as such - with 8 LSBs all being zero.
Or in some cases, the format may not provide a way to signal some bitdepth - which is common for 20-bits. There is no harm to encode it as 24-bit in a lossless format, other than filesize, but the flag that it originally was 20-bit may be lost.

This is all long after quantization, and its all in perfectly accurate integer, not floating points. :)

[madshi]

If you take a 20-bit signal, and you want to store it in a 24-bit format, what do you do? You pad it with zeroes.
Thats how its done everywhere, so you have no idea what the original bitdepth was when you get all zeroes, all the time.

Thats just a very common use-case when dealing with PCM, and eac3to wants to know if a signal was mastered wrong - since it occasionally happens that a 16-bit signal gets erroneously padded to 24-bit and encoded as such - with 8 LSBs all being zero.
Or in some cases, the format may not provide a way to signal some bitdepth - which is common for 20-bits. There is no harm to encode it as 24-bit in a lossless format, other than filesize, but the flag that it originally was 20-bit may be lost.

This is all long after quantization, and its all in perfectly accurate integer, not floating points. :)
Exactly. The reason why I added the "VALID_BITS" tag in the first place was because many TrueHD and DTS-MA tracks are encoded as 24bit, but have a number of bits set to zero throughout the whole audio file. I've seen TrueHD/DTS-MA tracks detected by eac3to with anything between 16 and 24 bits (20 bits is common, but IIRC I've also seen e.g. 18bit or 22bit). Many tracks even have different bitdepths per channel! So this tag signals the number of bits that eac3to found to be set to non-zero anywhere throughout the audio file. Whether this information is considered useful by anybody or not is an entirely different question. But this is how VALID_BITS has always been "meant" by eac3to.

Maybe I should have named it "NON_ZERO_BITS". But to be honest, all those years ago when I added this tag I considered it a "private" eac3to flag and didn't think anybody would be interested in reading/displaying it.

[Zenitram]

If you take a 20-bit signal, and you want to store it in a 24-bit format, what do you do? You pad it with zeroes.

Please read again my comment (especially the example with silence), I don't say something else.
I just say that this is not bidirectionnal i.e. zeroes in the lowest bits does not means that this was a 20-bit signal for sure (it may be a 24-bit format with zeroes in reality), you can just say that there is 99.9999% chances that this is the case.
Silence is a good example: silence, all bits 0 everywhere, that does not mean that 0 bits are valid. Same with a square signal.

And as I also said, I understand the reason it is made, but this is not a reason for changing reality of mathematics, and relying on only this check is not perfect. If you can rely on something else (e.g. metadata) please priotize this method over zeroes checking (zeroes checking should be only a fallback in the case there is not such metadata)

[Zenitram]

So this tag signals the number of bits that eac3to found to be set to non-zero anywhere throughout the audio file. Whether this information is considered useful by anybody or not is an entirely different question. But this is how VALID_BITS has always been "meant" by eac3to.

Maybe I should have named it "NON_ZERO_BITS". But to be honest, all those years ago when I added this tag I considered it a "private" eac3to flag and didn't think anybody would be interested in reading/displaying it.

Got it. "VALID" term was something misleading for me, I'll change the behavior of my own tool when I detect such tag.