Audio Asylum Thread Printer
Get a view of an entire thread on one page
|For Sale Ads|
In Reply to: RE: To be precise... posted by Charles Hansen on May 30, 2017 at 17:11:45
>The end result is that I am confident that Ayre's implementation is
>bit-accurate with the original, while the other versions I've seen are not.
Thanks very much for the explanation, Charley. I asked because I have
been getting some anomalous results ripping HDCD discs with dbpoweramp,
in that the true bit depth of the resultant file varies. I did wonder if this was
due to interpolated disc errors during the rip.
Edits: 05/31/17Follow Ups:
> > I have been getting some anomalous results ripping HDCD discs
with dbpoweramp, in that the true bit depth of the resultant file
varies. I did wonder if this was due to interpolated disc errors
during the rip. < <
I seriously doubt that any possible errors in HDCD decoding would lead to this result. Following is the curve for the Peak Extend (PE) function given by Keith Johnson in the AES preprint:
The vast majority of the possible values map in a 1:1 relationship, which results in the 45 degree line at the left part of the graph. The end point is also trivially calculated, as it simply compresses the input signal by 1 bit (= 6.02dB). The errors I've noted in all of the available versions of software HDCD decoders are simply in the shape of the curve. This would translate as a slightly non-linear transfer function and therefore introduce a small amount of harmonic distortion - but *not* a meaningful change in the amplitude of that signal.
I would guess what you are seeing is simply variations in the amount of "headroom" the mastering engineer left in the recording. Modern "loudness war" pop material would always have full-scale audio data. With Peak Extend, this would expand the 16 bits available from the Redbook format to 17 bits. But dBpoweramp puts the decoded data into a 24-bit container (for compatibility reasons), and pads the 7 LSBs with zeroes.
On the other hand I have seen some recordings, especially those of classical music and/or audiophile labels that leave more headroom. The signal rarely (if ever) even gets within a few dB of 0dBFS. Depending on the tools used to measure the bit depth, it seems possible that they might simply report the number of *active* bits and ignore the static zero bits used for padding. In that case a recording that never used the very top bits might be reported as having a lower bit depth. However, this is all just guesswork on my part as to what you are seeing.
As always my posts reflect my own opinions, and not necessarily that of my employer or cable installer.
The other thing about dBpoweramp (which I use and love) is that they have established what I believe is the best method to ensure the accuracy of a rip, which they call Accurate Rip. When you rip a CD, it creates a checksum which is then compared to the checksums of all of the other rips of the same disc from other users world-wide. When you have > 3 rips from different users with different discs and different CD mechanisms all giving identical MD5 checksums, one can be absolutely confident of having a bit-perfect rip.
While both Apple's iTunes ripper and Exact Audio Copy (EAC) use some tricks to ensure an accurate rip, the dBpoweramp ripping software also performs the same tricks. However it alone can compare your rip to those of other users with different discs and CD mechanisms. When ripping an HDCD disc you should also be able to use dBpoweramp's Accurate Rip feature to ensure that the rip itself is bit perfect and that there have been no interpolated errors. If you are getting bit-perfect rips of your HDCDs, I don't see any way that dBpoweramp's HDCD decoding could possibly be so poor as to affect the decoded bit depth.
dBpoweramp has always been at the forefront of digital audio tools. There was a period of many years where their reverse-engineered ALAC encoder out-performed Apple's own tools. Specifically if one used iTunes to transcode a high-res file to ALAC, it would play perfectly fine. But if one took that same ALAC file and transcoded back to WAV with iTunes, it would be truncated to 16 bits. It took years for Apple to correct, but dBpoweramp's version never had a similar problem.
As usual all postings strictly my own opinions, and not necessarily that of my employer or organ-grinding monkey.
Two winters ago, I ripped my whole CD collection using dBPowerAmp. Having no desktop computers in the house--indeed, no computers with built-in optical drives--I used my laptop with external drives. I found that a minority of the CDs I ripped--somewhere in the 10-20% range--were hard to rip; they were often new and perfect-looking, but they'd get caught up in dBPoweramp's error-correction algorithms. (Not a complaint about DBPoweramp--just wait and I'll get to the point.)
When I was maybe halfway through, after a particularly frustrating rip, on a whim I pulled out a Gordon-Rankin-designed AQ Jitterbug and added it between my laptop and the external drive. After that, I didn't have a single frustrating rip. I didn't do the math, but this is a convincing sample: Hundreds of trials with and without. circa 10% error rate without, 0% error rate without.
If you need to rip a ton of CDs, I highly recommend the combination: dBPowerAmp +AQ Jitterbug.
As Paul Simon said on some recording or other circa 1969--was it the Carnegie Hall one?--, "Apropo of nothing..."
> > I pulled out a Gordon-Rankin-designed AQ Jitterbug and added it between my laptop and the external drive. After that, I didn't have a single frustrating rip. < <
That is a *great* story. And I would agree that its really not worth the trouble to "scientifically" test it by re-ripping the same disc with and without the JitterBug - life's too short. The likelihood of it being a coincidence must be extremely small. Gordon has stated that he has seen USB packet errors due to noise on the connection that are corrected by the JitterBug. Your experience would seem to corroborate this.
I've never used an external drive, but I also use dBpoweramp and have had similar problems with "difficult" rips that have tried my patience. I don't want to open up my laptop and try to install a JitterBug inside, but certainly can imagine that whatever was causing the problems in your setup could also affect other external devices, such as DACs. Thanks for sharing.
Thanks for the detailed responses,Charley. I did use dBpoweramp's Accurate Rip so
am not sure why I was getting anomalous results. This was with a. DAC that indicated
bit depth on its display, BTW.
1) A decoded HDCD file will only have a maximum number of active bits of 17 in most cases (1 extra bit if Peak Extend (PE) is engaged) or possibly 18 in rare spots in some tracks with extremely quiet passages if both PE and Low Level Extension (LLE) are engaged. (Please remember that PE is always on for the entire disc, while LLE - if engaged - only auto-activates when the peak signal level falls below -45dBFS.) This audio data could be placed into word with lengths anywhere between 18 and 32 bits before being transmitted.
We don't know exactly how dBpoweramp packs the 17- (or sometimes 18-) bit data. The two obvious choices are to pad the LSBs to create either 20-bit words or 24-bit words. I would imagine that 24 is the more likely number. One way to check this would be to compare the file sizes of the undecoded and decoded tracks (taking care to avoid erroneous reporting due to the smallest cluster size created during disk formatting). Also different transport protocols (eg, S/PDIF, USB, Ethernet) may have different word lengths permitted.
2) We don't know exactly how the DAC calculates the reported bit depth. One way would be to count the number of bit clocks per word clock. It is conceivable that this could vary at different points in the DAC's circuitry due to the way that different transmission protocols are decoded. Another way is to simply read the Status Bytes in incoming S/PDIF data. If the professional format is used (as opposed to the consumer format), the source can optionally send data on bit depths for 16, 18,19, 20, 22, 23, and 24 bits - but *not* 17 or 21 bits.
The only thing of which I am confident is that once we understand what is happening, it will all make perfect sense in hindsight... :-)
Post a Message!
This post is made possible by the generous support of people like you and our sponsors: