Ripping HDCD audio

They do, and supposedly the DAC in the Squeezebox Touch is one (although I haven't confirmed that personally, just going by other published info).

 

Why not? I use High-Rez & HDCD-decoded sources for MP3 creation all the time (I apply track or album ReplayGain while converting to MP3 too for use with my portable DMP). BTW MP3 utilizes float representation, not integer, so it should work fine for any source bit depth IMHO...

 

I've just never gotten around to finding out what LAME would do if you fed it a 24 bit source and what would the iPod do when playing it back. I'm lazy. I could use dBpoweramp to do the conversion. It has a processing option that will convert from 24 bit to 16 bit before the encoding. But I'm lazy. I use JRiver for managing the iPod and doing the FLAC to MP3 encoding when syncing the iPod. JRiver doesn't have an option for doing a 24-bit to 16-bit conversion during encoding. But maybe I don't even have to worry about that because of the way MP3 encoding/decoding works?

Hmmm... now I'm going to have to experiment and research. Blissful ignorance was less work.

 

Where did you read this, and is there a way to do a quantitative test to confirm?

 

Stereophile's 2011 Buyer's Guide. I'm sure you could test it, but I'm not interested enough to experiment.

 

The Green Day "nimrod" CD would be a good test. It has peak extension. The difference in peak dynamics for the decoded and undecoded sound is easy to hear. It is one of the most obvious HDCD samples that you can identify just by listening.

Play the CD on a standard CD player and then on the Squeezebox Touch. You'll be able to tell if the Squeezebox Touch is decoding.

 

Unfortunately, I don't have that CD. I did discover, though, that Foobar doesn't recognize HDCD encoding in ALAC files.

 

Nimrod is available on Amazon used for as little as $0.01 + $2.98 shipping. It may not be great music, but it is a great HDCD test disc.

Foobar HDCD decoding not working with ALAC is surprising. I tried it. It didn't work. I wonder why? There is a recent thread (from March) on the Foobar forum at Hydrogenaudio that mentions the problem. I assume the Foobar developer is aware. I hope it gets fixed.

 

Do the Oppo players (I have a 93) decode HDCD if the source is a FLAC file over DLNA? Or do they only decode from CD?

 

Thanks for this info. It's exactly what I've been looking for.

 

I can't seem to get CUETools to show me whether or not HDCD was detected when I view the log. I have the "Detect HDCD" function activated and am using a confirmed HDCD disc (Hard Promises). Is there anything else I'm missing?

 

The recent versions of CUETools don't properly report HDCD if present. If you run a "verify" it should detect and log the HDCD. If you run an "encode" it doesn't report HDCD in the log. I haven't tested to see if it actually does a proper HDCD decode even though it's not reported in the log.

I continue to use version 2.0.9 because it handles HDCD detecting and decoding the way I'm used to and the way I expect. Here's a download link for 2.0.9.

 

Thanks!

 

Does anyone know why when decoding an HDCD in CUETools to a 20-bit file (not a padded 24-bit one) the resulting file still peaks below -6dB? This suggests that the audio within is still only 16-bit and padded with zeros, does it not? I expected the audio to occupy the full 20-bit depth. Also, whether decoding to either 20-bit or padded 24-bit, the file size is not increased by more than a negligible amount. Again, this suggests that the audio is not any higher in resolution.

Or am I completely off the mark here? I'd love an explanation if anyone is up to it!

 

If Peak Extension wasn't used, the max peak after decoding will be -6 dB.

Keep in mind the extra 4 or 8 bits are at the low end of the scale. That is, 0 dB is 0 dB regardless of bit depth. The ~6 dB (1 bit) shift from decoding is something specific to the HDCD decoding process - normally, converting from 16 bit to 20 or 24 bit won't change the volume.

Also, FWIW, while I don't know if this is ever the case, in theory a disc could employ Low Level Range Extension but *not* Peak Extension. As such, when decoded it would never peak above 6 dB but *would* (could) have additional resolution in quiet sections.

 

Ahh, my bad. I was thinking 6dB represented 4 bits, but you're right - it's only one bit. Thanks for clarifying that. So the audio is still occupying 19 bits of the 20-bit container. O.T. but do you know if I'm right in thinking that if I were to convert this decoded audio to a 24-bit file with +6dB gain, I would need to employ dither?

 

I'm not sure what your intentions are, but if the original audio doesn't utilize PE or LLRE, there's no need to decode it in the first place. As far as going from 16-bit or 20-bit to 24-bit goes, there's no need to dither. If you do have something with LLRE but without PE, and you want to make up that ~6dB loss, your best bet would be to find something that will do a bit shift.

 

Version 2.1.4 appears to be flagging them properly in my scans. Here's the 2000 Remaster of Van Halen's 1984 for an example:

Code:

[CUETools log; Date: 4/22/2012 12:13:42 AM; Version: 2.1.4]
HDCD: peak extend: none, transient filter: some, gain: none
[CTDB TOCID: vA7TMwH5gmYbhpgRMeRXBldJtyM-] found.
Track | CTDB Status
  1   | (15/15) Accurately ripped
  2   | (15/15) Accurately ripped
  3   | (15/15) Accurately ripped
  4   | (15/15) Accurately ripped
  5   | (15/15) Accurately ripped
  6   | (15/15) Accurately ripped
  7   | (15/15) Accurately ripped
  8   | (15/15) Accurately ripped
  9   | (15/15) Accurately ripped
[AccurateRip ID: 000a80ff-004ff68d-5d07d809] found.
Track   [  CRC   |   V2   ] Status
 01     [e0450f76|aca07b07] (135+020/180) Accurately ripped
 02     [94df7265|8d2826eb] (134+021/180) Accurately ripped
 03     [e621773b|1b4c3cf5] (133+022/180) Accurately ripped
 04     [28e2c558|d05d8dfd] (132+021/178) Accurately ripped
 05     [3ffaf6a9|a9417f9b] (132+021/178) Accurately ripped
 06     [3bbb6f76|fc9afce3] (128+021/176) Accurately ripped
 07     [a87ec8ee|75e69ce1] (132+021/178) Accurately ripped
 08     [9c9614ad|c44f2320] (132+021/178) Accurately ripped
 09     [29eb1cc2|d7f4da0f] (131+021/176) Accurately ripped

Doing a scan for HDCD tracks on the same files in Foobar shows "Intermittent" for Transient Filter, "None" on the other options.

 

Interesting. Was that doing an "Encode"?
It reports HDCD for me but only during a "Verify". I just did a test with Green Day's "Nimrod" and it did properly decode the HDCD and split to individual FLAC files for an "Encode" even though the HDCD results did not show up in the log. So at least it is working even though it doesn't log correctly.

Maybe my problems are due to something like a .NET assembly versioning or dependency problem. I'll take a look when I have some time.

 

Doing an encode to a separate directory from the files gave me a log that doesn't flag HDCD, but the actual files did show same results as before in Foobar. Scanning the new files (overwriting the log) adds the HDCD flag back in. Same file CRCs in logs. It must just not report HDCD in logs created from encoding.

 

That's the same behavior I'm seeing. I hope that gets fixed in a future version of CUETools.

For now I'll stay with 2.0.9 but I miss out on the AccurateRip V2 verification and the new CTDB. One of the reasons I use CUETools is to detect and then decode HDCD. I could change my workflow and go back to using dBpoweramp to rip and let dBpoweramp detect HDCD. But I tend to stay with old habits and methods until something really forces a change. I like how CUETools reports what HDCD features are enabled. dBpoweramp doesn't do that.

 

Clipping from +6dB setting

I recently ripped some HDCD-encoded Neil Young discs with dBpoweramp's HDCD DSP. I've found that the default setting of applying +6dB amplification to compensate for the volume change from 16 to 24 bit conversion very often results in 24 bit waveforms with clipping. The pics below show "I'm the Ocean" from the Mirror Ball HDCD (Foobar2000 says PE: yes LLE: 0.0db TF: no).

The first waveform is the result of dBpoweramp's default +6db setting. Audacity shows the clipping with red lines. The second waveform is the result of disabling the +6dB setting. As you can see, the file has no clipping, but also plays back pretty quietly on my iMac/iTunes/Pure Music combo (which doesn't recognize and/or apply the Replaygain tag). I then used Audacity to amplify the middle waveform without clipping (in this case, +4.0dB). The result is the third waveform which, of course, plays a bit louder.

I definitely think the +6dB default setting should be disabled when ripping HDCD's to 24 bit in dBpoweramp. However, applying amplification to each individual track is very inconvenient. Also, while I don't hear any obvious offensive artifacts in the third file, I wonder if it's inferior to the the second file.

Can someone tell me if applying amplification in a program like Audacity creates a file that, while not clipped, has degraded sound? Does this amplification decrease the dynamic range of the file? Should I just keep the quieter files and adjust the volume on my amp on a per album basis?

 

^ IMO you should not apply automatic +6dB gain while decoding HDCD material encoded with PE. The whole point is to give a 6dB headroom for the soft limited (during the encoding stage) peaks to be extended... You can always analyze the decoded tracks/album and see what gain would be safe to use to avoid clipping (I personally prefer using ReplayGain however)

 

The red lines are what Audacity calls clipping based on their algorithm and your settings. It doesn't mean that it is really clipping since it depends on how many samples you have the threshold set to. If it's only set to 1 or 2 samples, you can't reliably tell, it may just mean the digital peak hit 0db. You would have to expand it to see.

Of course, if you checked the waveform beforehand and the max digital peaks were at -4db, then +6dB would obviously be too much.

 

Agreed