Skip to main content ↑ ↓

Notice

Please note that most of the software linked on this forum is likely to be safe to use. If you are unsure, feel free to ask in the relevant topics, or send a private message to an administrator or moderator. To help curb the problems of false positives, or in the event that you do find actual malware, you can contribute through the article linked here.
Topic: HDCD "per track" decoding issue (Read 1759 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

HDCD "per track" decoding issue

Notice the whole lotta "seems" to follow, seemingly calling for comments, corrections, insults and maybe even (*gasp*) testing. I have posted fragments of this in other threads, after playing around with hdcd.exe / CUETools' HDCD features / foo_hdcd : https://www.hydrogenaud.io/forums/index.php...mp;#entry906496 and https://www.hydrogenaud.io/forums/index.php...9427&st=397

So I have advocated keeping a HDCD rip undecoded lossless for two reasons: (I) decoding is irreversible, and (II) one can decode on-the-fly upon playback. What I have found, indicates another argument against decoding (from tracks!), and one argument against on-the-fly decoding: the latter is that my decoding solution (foo_hdcd) is not bit-exact (see the latter of the above two links).


Now here is the hdcd.exe-decoding-by-tracks issue: hdcd.exe seems not to decode the very beginning of the input; only after it has read enough samples to identify HDCD.
That is: if fed individual tracks, it would switch off HDCD decoding briefly at the beginning of each.

Assuming that the goal of HDCD decoding would be to mimic actual HDCD playback through a DAC that is fed an SPDIF signal without track boundary information, the "good" thing to do is to start decoding as soon as HDCD is identified in track 1, and then go on for as long as a HDCD-aware DAC would do.
(Presumably for the entire CD if done properly?) So we have a case for image-based conversion.

But some CDs only have a subset of tracks as HDCD.  And it seems to me that hdcd.exe only scans the first 750 frames. I conjecture it has no way of switching off HDCD. That is an issue against converting a full image. One should then use hdcd.exe -i to identify each track, and then decode-as-one each "contiguous set of HDCD tracks"?


It seems that CUETools - which uses the .dll version of the hdcd.exe utility, but works inherently on full CD rips (and can enforce reading past 750) - is immune against the beginning-of-track issue.



HDCD "per track" decoding issue

Reply #1 –
It takes many samples to detect an HDCD signal (or the loss thereof), and during that time, the decoder must use whichever HDCD settings were previously set.

When you play a whole CD, the start of each track will be played using whatever HDCD settings were enabled at the end of the previous track, until the decoder is able to detect the new settings or loses the HDCD signal and turns all HDCD features off. This is why the differences you see are always at the beginning of a track.

If your goal is to imitate an HDCD-capable DAC, you should perform full-image HDCD decoding for all of your CDs, regardless of HDCD content. (HDCD requires extra headroom, so it reduces the volume of everything else by about 6dB.)

Quote from: Porcus on
And it seems to me that hdcd.exe only scans the first 750 frames.

Only when you use the -i flag. If you don't use the -i flag, it will check the entire file and correctly report HDCD even if no HDCD is present for the first 750 frames.