> Regarding dithering, I am not aware of many programs that do that without > very specific user selection. Any user savvy enough to turn on dithering > would hopefully be paying attention well enough to avoid promoting 16-bit to > 24-bit without noticing their mistake.
I suspect that this is sometimes done dishonestly in order to sell hi-fi enthusiasts DVD-A's made from lower-quality source material. After all, they do sell $35 dollar "high definition" digital coaxial S/PDIF cables at your local Radio Shack. And you lost me on the last paragraph there, but that's okay. Thanks for the clarification. - BW On Sat, Jan 8, 2011 at 1:13 AM, Brian Willoughby <[email protected]> wrote: > > On Jan 7, 2011, at 21:38, Brian Waters wrote: >>> >>> My 16-bit detector does exactly that, except that it only looks for >>> 0x00 in the lowest 8 bits of each sample. >> >> What if the program that did the 16-to-24 conversion also did some >> dithering? If I'm not mistaken, that would probably be the case if >> they did some sample rate conversion as well (maybe they were going >> from CD quality up to 24/96). In that case, shouldn't your program >> look for values in the LSB that are under a certain threshold, instead >> of just zeros? > > That's a very good suggestion, and would be appropriate for a more advanced, > but fuzzy detection. > > My program was designed to catch the absolute simplest case of setting your > DAW to 24-bit files when recording from a 16-bit interface. Or, if you have > a 24-bit digital audio interface, but feed it from a DAT. > > In fact, the day I wrote the program was when I was transferring an > 18-channel live recording that I made for a band that wanted to tour Europe > based on a live demo, where 16-channels were 24-bit A/D and the extra 2 > channels came from my old DAT via AES/EBU. Even though I knew that the DAT > channels couldn't possibly be full 24-bit, I still wanted to confirm that I > would not lose anything by converting the master files to 16-bit. I archive > all recordings using FLAC to save space, and a 16-bit FLAC would obviously > take less room than a 24-bit FLAC. > > > Regarding dithering, I am not aware of many programs that do that without > very specific user selection. Any user savvy enough to turn on dithering > would hopefully be paying attention well enough to avoid promoting 16-bit to > 24-bit without noticing their mistake. > > Regarding 16/44.1 up-conversion to 24/96, I would notice that in the FFT, > because there would be nothing but very low-level quantization noise above > 44.1 kHz. But this sort of thing is a manual process for me now, not > automatic. I imagine that it would be especially difficult to detect > aliasing in an up-conversion, at least with software, but it's almost > completely obvious to a human looking at the linear frequency FFT display. > By the way, the 44.1 kHz to 96 kHz conversion would create valid 24-bit > samples - there would be nothing "16-bit" about them any more. Because of > the change in sample rate, the 16-bit values would fall in between sample > periods, and thus the exact sample would hopefully use the full 24 bits for > maximum accuracy. In my opinion, all sample rate conversions should > preserve the 24-bit results. > > As for your suggestion to look for values in the LSB under a certain > threshold, I think that you have a misunderstanding about dither. The LSB > would always be changing in dithered material, regardless of amplitude > thresholds. Dither has to be applied to all samples, loud or quiet, or else > it doesn't do its job. In other words, dithered audio is going to have > constant motion in the LSB. I do think that a dithered 16-bit file stored > in 24 bits might have some patterns, such as perhaps all 1s or all 0s, but > there's no guarantee. Dithering starts by adding noise, and so the > intermediate result has valid bits everywhere. When the dither process is > complete, the result should be masked so that the 8 LSBs are all 0, but if > the masking isn't done then they really could be anything. I have noticed > interesting patterns with bit meters, but I'm not sure whether to trust a > bit meter that I did not write myself, as the two I have used show > completely different pictures of the same digital audio stream. > > Brian Willoughby > Sound Consulting > > _______________________________________________ Flac-dev mailing list [email protected] http://lists.xiph.org/mailman/listinfo/flac-dev
