On Jan 7, 2011, at 18:08, Declan Kelly wrote:> On Fri, Jan 07, 2011 at 05:11:26PM -0800, brianw at sounds.wa.com wrote: > [NIN 24/96] > >> Thanks! That's interesting to note. I think that I ended up with >> the true 24/96 files, but I am curious: How do you tell whether you >> have the full 24/96 or not? > > Extract to WAV, do a hex dump, and look for repeated 0x00 bytes. > Someone > on the hydrogenaudio forums did that, reported it on the NIN > forums, and > Reznor got the reissued 24/96 FLAC'd and seeded on tracker.nin.com > in a > couple of days.My 16-bit detector does exactly that, except that it only looks for 0x00 in the lowest 8 bits of each sample. I used to use hexdump, but didn't trust my eyes when scanning manually. With a program, there aren't any false positives for 0x00 bytes in other positions. What it does is scan until the first sample is found with something in the lowest 8 bits, and then reports the file as true 24-bit and quits early. If it scans the entire file without finding any 24-bit values, it gives the sad news that it's really 16-bit samples disguised as 24. By the way, I had to special-case 0x00800001 and treat it as 16-bit. I don't know whether it was the MOTU 896HD or Logic, but something was creating that one value in the midst of an otherwise 16-bit pure file. But there are tens of millions of other 24-bit values, so ignoring that one won't create a false report.>> 16-bit audio samples stored in a 24-bit file format. Frequency >> analysis makes it obvious whether the content extends above 20 kHz. > > Google for that hydrogenaudio thread: Reznor made one post on it, and > mentioned that the recording was done at both 24/96 (Lavry) and 24/192 > (Apogee) on all songs, and they chose whichever they preferred at mix > time.Thanks. Brian
> 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? Again, forgive me if I'm misinformed here, this isn't really my specialty. - BW On Sat, Jan 8, 2011 at 12:31 AM, Brian Willoughby <brianw at sounds.wa.com> wrote:> > On Jan 7, 2011, at 18:08, Declan Kelly wrote: >> On Fri, Jan 07, 2011 at 05:11:26PM -0800, brianw at sounds.wa.com wrote: >> [NIN 24/96] >> >>> Thanks! ?That's interesting to note. ?I think that I ended up with >>> the true 24/96 files, but I am curious: How do you tell whether you >>> have the full 24/96 or not? >> >> Extract to WAV, do a hex dump, and look for repeated 0x00 bytes. >> Someone >> on the hydrogenaudio forums did that, reported it on the NIN >> forums, and >> Reznor got the reissued 24/96 FLAC'd and seeded on tracker.nin.com >> in a >> couple of days. > My 16-bit detector does exactly that, except that it only looks for > 0x00 in the lowest 8 bits of each sample. ?I used to use hexdump, but > didn't trust my eyes when scanning manually. ?With a program, there > aren't any false positives for 0x00 bytes in other positions. ?What > it does is scan until the first sample is found with something in the > lowest 8 bits, and then reports the file as true 24-bit and quits > early. ?If it scans the entire file without finding any 24-bit > values, it gives the sad news that it's really 16-bit samples > disguised as 24. > > By the way, I had to special-case 0x00800001 and treat it as 16-bit. > I don't know whether it was the MOTU 896HD or Logic, but something > was creating that one value in the midst of an otherwise 16-bit pure > file. ?But there are tens of millions of other 24-bit values, so > ignoring that one won't create a false report. > > >>> 16-bit audio samples stored in a 24-bit file format. ?Frequency >>> analysis makes it obvious whether the content extends above 20 kHz. >> >> Google for that hydrogenaudio thread: Reznor made one post on it, and >> mentioned that the recording was done at both 24/96 (Lavry) and 24/192 >> (Apogee) on all songs, and they chose whichever they preferred at mix >> time. > > Thanks. > > Brian > > _______________________________________________ > Flac-dev mailing list > Flac-dev at xiph.org > http://lists.xiph.org/mailman/listinfo/flac-dev >
> 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 <brianw at sounds.wa.com> 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 > >