Skip to main content

Topic: Extract HDCD (Read 166041 times) previous topic - next topic

0 Members and 1 Guest are viewing this topic.
  • user
  • [*][*][*][*][*]
Extract HDCD
Reply #125
The answer is satisfying,
don't worry, be happy

Pregaps don't matter, offsets don't matter, and directly skipping into a track does not matter also, all for positive HDCD decode.

I tell this by practical experience with HDCD,

I transmit normally flac song track files via optical digital connection into a Harman kardon receiver/amp, which has the ability to deal with eg. up to 24/96 kHz PCM, and HDCD decode for this topic.

or a HDCD playing from CD/DVD-player digitally connected to that amp.

With both HDCD sources it does not matter, you can directly skip (either by foobar's time slider or by fast forwarding eg. with the CD/DVD-player) into the mid of a track, and after very short time the Harman Kardon amp/decoder detects it as HDCD and shows the HDCD symbol.

If somebody could prove the opposite eg. by the test of cutting an existing HDCD flac/wave file, and the cut part of this wave would not show HDCD anymore, I would be surprised. -- High Quality Audio Archiving Tutorials

  • krabapple
  • [*][*][*][*][*]
Extract HDCD
Reply #126
OK, I did the experiment.

ran hdcd.exe -a on this undecoded track:
03 - Mixed Bizness.wav (from "Midnite Vultures" by Beck)
HDCD detected
Packets Processed  3345
Peak extend never enabled
Min gain  0.0dB
Max gain 0.0dB
Transient filter enabled intermittently

Copied and saved a 1-minute excerpt from the middle, using Audition ('snap to zero crossings' enabled); ran hdcd.exe -a on it
03 - Mixed Bizness_excerpt.wav
HDCD detected
Packets Processed  860
Peak extend never enabled
Min gain  0.0dB
Max gain 0.0dB
Transient filter enabled intermittently

  • Last Edit: 16 September, 2009, 01:02:53 PM by krabapple

  • Aquares
  • [*]
Extract HDCD
Reply #127
This tool is pretty interesting. I haven´t much HDs but one of them "Yim Hok-Man - Poems Of Thunder, The Master Chinese Percussionist" i bought for 7.95 at Amazon is a HD showing no sign of it on the box. Only a small info in the booklet about mastering equipment using it.
In the first song are some strong Kudo drumhits that are real distorted.
Decoding it with the peak extension found makes these drumhits absolut clear!
Looking in an editor shows the non decoded one as totally smashed.
I replagained both and did an abx in foobar with no problem.

Same e.g. with "Rupa & the April Fishes - Extraordinary Rendition". The album is rather dynamic and not very loud anyway, but there is some clipping that is reduced audibly and measurably after decoding.

I measured with ClippingAnalyzer to get some hard facts:

Track: Une Americaine à Paris

RMS (after normalization), L/R:  -13.2 / -12.2
No. of occurrencies, L/R:  97 / 270
Ø clipped samples per sec:  4.0    
No. of samples in longest clipping sequence:  21

HDCD Decoded:
RMS (after normalization), L/R:  -15.9 / -14.9
No. of occurrencies, L/R:  0 / 11   
Ø clipped samples per sec:  0.1
No. of samples in longest clipping sequence:  6

  • Gumboot
  • [*][*]
Extract HDCD
Reply #128
So I've been looking at hacking code to be bit exact with hdcd.exe (since I don't want to mess around with WMP plugins), and in that process I have to make sure I know what it's doing.  To put aside any doubt, I made up a test file which extracts the envelope function by encoding a DC signal and injecting various HDCD codes to move the gain around.  [Can I attach that?  I don't see a button.]

When gain changes, it steps in multiples of 1/4096.  This quantisation is being multiplied into the audio signal as the gain changes.  If this is the complement of the gain function applied by the encoder then there's no problem, except for the non-HDCD listeners who would have that error function multiplied into their version with no correction.

What worries me is the behaviour of HDCD.EXE (and presumably WMP too).  The point at which these quantised steps are taken depends on the starting value of the gain.  For example, a ramp from -0dB to -4.5dB proceeds through a fixed set of gain values for each audio sample, but a ramp from -0.5dB to -4.5dB is not the obvious subset of those.  I don't know for sure if this behaviour is bit-exact with WMP, but I'm doubtful that it would be bit-exact with a hardware implementation, because it would cost extra resources to be that erratic.

When there's a mis-step in an implementation's ramp, that's a transient miscalculation of a single sample by a factor of 1/4096, reducing the meaningful resolution in that area to (worst case) 12 bits.  It's a trivial error and likely completely imperceptible, but with all this effort going into lossless storage and high-resolution DACs and post-processing on 16-bit audio to get extra resolution out, it's not really what we want to happen.

So I have to ask: Is HDCD.EXE correct?  Is WMP correct?  Is the PMD-100 correct?

My inclination is to assume that the ramp should be perfectly smooth, as that would minimise loss for both HDCD and non-HDCD listeners, and that the quantisation is a numerical simplification for a desktop implementation only.  I don't know for sure, though, and finding out would require more signal analysis than I can be bothered with, or a reference encoder.

  • Gumboot
  • [*][*]
Extract HDCD
Reply #129
Lest I be accused of doing my necromancy by half measures...

Ah, the fun old HDCD question. Was browsing on another forum today and the topic came up, which reminded me of an old, unanswered question I had regarding HDCD decoding. Specifically, from this thread. Money quote: "Any idea if [pregaps actually missing] affects HDCD playback?" From what I understand, the HDCD information is stored in the "LCBs" (least significant bits) and in only a minority of the... samples? I suppose, then, the key question is whether any HDCD "flags" are set in pregaps. My guess is no (are pregaps even audio information, really?), but it would be nice to know for sure.

By the way, something else I was wondering: what if your rips aren't offset correctly (in EAC, drive offset I mean). Does the HDCD "flag" rely on correct alignment (or cue sheets) as a reference? If each sample (or whatever) contains the HDCD information, than I suppose none of that would matter... and that might solve my missing pregaps question too.

The HDCD flags are typcially repeated ten times a second.  The bitstream decoder is non-recursive, so to destroy one you have to cut a file somewhere within a 72 sample window.

The filter is not stateless, though.  You can begin playing with an incorrect setting for gain or peak extension.  Changing the state of peak extension is instantaneous, and so if the signal came right in the middle of a peak then you might get a bit of a pop.  The gain is ramped from wherever the decoder thought it was previously, so it'll be smooth(ish), but it can take up to 44 milliseconds to find the right value.

In short, if you cut an HDCD stream, you can expect up to the first 145ms to be less than perfect, but not significantly less than perfect.
  • Last Edit: 12 December, 2011, 12:51:34 PM by Gumboot