Improved HDCD information and logging

[twit]

For those of us with discs that have HDCD on them (many of us), there are many tradeoffs to consider in deciding whether or not to decode the HDCD information during ripping, or leave encoded for a player to decode.

Please provide the following technical information in the Ripper window, and please also write this to the rip log file:

1) HDCD detected (report as is done today)
2) HDCD peak extension use (report as a "Y" or "N" will work) (FWIW, mapped to "hdcd_peak_extend" by Foobar component via HDCD.exe)
3) HDCD transient filter use (areport s a "Y" or "N" will work) (mapped to "hdcd_transient_filter" by Foobar component via HDCD.exe)
4) HDCD gain (report whatever dB is used) (mapped to "hdcd_gain" by Foobar component via HDCD.exe)

I've learned the hard way that not all discs labelled HDCD use all or any of 2-4 above - some discs flag as HDCD but use none of them or only number 4, which means you are better off ignoring HDCD decoding (because Replaygain can do gain adjustments better). And HDCD.exe (what is used by Foobar and dBpoweramp to decode HDCD) only deals with 2 and maybe 4 but not 3, and only a few receivers or media players can decode HDCD in hardware, but if they do, they can handle all aspects well. And using Replaygain will prevent software players like WMP and Foobar from decoding HDCD at all, even if there is anything worthwhile to decode. And if you decode HDCD in a FLAC file, your playback system needs to handle 24 bits. Few users are probably aware of all of these considerations and tradeoffs, but that doesn't mean that they are therefore unimportant.

In short, sometimes it's better to decode HDCD during the rip, and sometimes it's better not to, depending on what HDCD attributes are really used and what one is using for playback. Rather than the current situation of guessing, please provide and write the information above to help users make informed decisions regarding HDCD. Thanks!

[iangrant]

Re: Improved HDCD information and logging

I never realised there were such variations in HDCD implementations, I am currently 'blindly' decoding all my HDCDs. I also didn't know there were any media streamers that could decode HDCD, I thought it was just CD players.

[iangrant]

Re: Improved HDCD information and logging

A further feature request: it would be good if dBpoweramp put 'HDCD (Lossless)' or something similar in the 'Source' meta data / tag when it decodes a CD, rather than 'CD (Lossless)' as is currently done.

[soongsc]

Re: Improved HDCD information and logging

I have some questions regarding HDCD, and wonder whether anyone has experience with it or not.

1. My understanding is that HDCD is supposed to solve nonlinearities in the ADC/DAC. Would'nt that mean they would be playback DAC specific? What would decoding them in software benefit? Sounds like we need sound cards that can decode HDCD.

2. Based on the first post, it seems the 2-4 means bits?

[Spoon]

Re: Improved HDCD information and logging

1. Not unless decoded to a larger bit depth then stored, this is the same as a 'dac' decoding on the fly

2. No means points in his remark 2 to 4

[twit]

Re: Improved HDCD information and logging

It would be great to add a tweak recently added by Foobar, which is to allow the selection on -6dB gain adjustment if peak extension is detected during decoding. While this or any gain change is irrelevant if one uses Replaygain tags and players, it's meaningful for situations where replaygain use is not possible.

[Spoon]

Re: Improved HDCD information and logging

The +6dB gain adjustment is an option for HDCD in dBpoweramp

[twit]

Re: Improved HDCD information and logging

Yes, I see the +6dB option. I thought that was for people who don't like the application of any HDCD gain adjustment (usually negative dBs), and probably don't use Replaygain all the time (since that would eliminate the impact of any gain adjustment prior to using Replaygain tags).

The -6 dB suggestion is for the peak extension aspect of HDCD, which occurs on some but apprently not all HDCD discs. The intention of applying -6dB when peak extension is detected is to reduce the potential for clipping after the peak is extended by the HDCD decoder for those who don't use Replaygain all the time. Again, if you use Replaygain then I think any gain adjustment by the HDCD decoder becomes irrelevant.

The existing HDCD.exe code you use already detects and applies peak extension when detected, as I understand from the Doom9 and hydrogenaudio forums. There's even a component for Foobar that displays the detection of peak extension, gain, and transient filters.

[bonkers]

Re: Improved HDCD information and logging

+1 for either showing if the peak extension flag was detected in the technical column and log, or adding an option to the HDCD utility to only decode HDCD if the peak extention flag was detected, or both. Just showing "HDCD" in the technical column and log without indicating anything else about HDCD is pretty much useless.

[Porcus]

Re: Improved HDCD information and logging

+1 for either showing if the peak extension flag was detected in the technical column and log, or adding an option to the HDCD utility to only decode HDCD if the peak extention flag was detected, or both. Just showing "HDCD" in the technical column and log without indicating anything else about HDCD is pretty much useless.

Unless you rip to a lossy format, I don't see any reason to use the HDCD DSP upon ripping. It can be applied retroactively if you wish.

My earlier 2 cents on the matter:

http://forum.dbpoweramp.com/showthread.php?25648-Questions-about-DSP-s&p=119732&viewfull=1*post119732

http://forum.dbpoweramp.com/showthread.php?25598-24bit-HDCD-FLAC-rips-playing-16bit&p=119712&viewfull=1*post119712

[bonkers]

Re: Improved HDCD information and logging

Yes, I read those posts, and I appreciate that you took the time to explain your view. I think there are tradeoffs no matter what. In my case, I find it difficult to ensure that my lossless streaming setup correctly switches back and forth between 16 bit and 24 bit without unnecessary transformations (I have different setups in different rooms, and I occassionally change software or hardware, so staying on top of this is a pain), so I prefer to ignore HDCD decoding completely if PE is not enabled and reduce the number of lossless albums that I have at 24 bit, without completely giving up on any potential HDCD benefits for those that have PE enabled. I think the transient filters are only relevant when upsampling (saw that in a hydrogenaudio discussion I think), and I use replaygain so the gain flag is irrelevant to me.

I find it far easier to make the decision to decode or not decode HDCD when ripping, because it's very difficult to selectively decide to decode or not when streaming. I have also found very little hardware that decodes HDCD so I don't want to limit my options to just hardware decoding.

If streaming becomes a far simpler and clearer process so that various bit rates and sample rates are automatically handled without needless transformations as a universal standard feature, and if decoding HDCD streams can accept logic that only decodes HDCD if certain flags are enabled (I use foobar2000 and I don't see such a feature), then I would switch to do what you do.

Perhaps when the HDCD patent expires in Feb 2017 we can resolve the mysteries of what HDCD.exe really does (the developer of HDCD.exe won't reveal his code out of respect for the patent while it's still in effect), and then refine the best course of action, but by then I will probably have forgotten about this.

But for now, I'd prefer to have dBpoweramp to report what HDCD flags are detected, and most especially the PE flag, so that I don't have to stop ripping when HDCD is detected, start up foobar2000 to find out what flags are present, and go back to dBpoweramp to rip. Since dBpoweramp already detects HDCD flags, I don't see this request as a major effort to implement, but I could be wrong.

[Porcus]

Re: Improved HDCD information and logging

You use foobar2000, as I do. I use the foo_HDCD component, where you can configure as follows:

Under Preferences --> Advanced --> Decoding (the top expansion box) --> HDCD decoder, you can choose to halve output volume
(_) Always
(_) Never
(o) Only if peak extension is enabled.

Was that the feature you didn't see? (Took me two minutes to find it even now I knew it was there.) AFAIK, that will prevent the 'extra bits' except when PE is enabled. (Then of course, Tool's 'Lateralus' is reputed to have PE only on complete silence, which is pretty much nonsense, right?) When it comes to the transient filter, there is AFAIK no software solution -- not hdcd.exe, not foo_HDCD, nothing known -- which can do anything about it. Which is a reason to leave them as ripped until 2017


If you play albums (not playlist one track from each), then you probably want to check the entire CD before deciding, and then you should rip the entire CD first, IMHO. In foobar2000: right-click --> utilities --> scan for HDCD.


Or, you could maybe write a script that traverses the directories and runs hdcd.exe -i on every file, sending exit codes to a log file. You don't have to interrupt ripping, of course -- do all ripping first, all HDCD scanning next, and then review your logs by searching for the exit code that indicates HDCD found.


That said, the exit codes of hdcd.exe makes it easy to log what happened, and I do support that request (... I nagged Spoon quite a lot on logging pre-emphasis ...). I would even suggest logging without decoding (just tell that HDCD found, and what features) -- although I have no need of it as long as I want to use foobar2000.

[Porcus]

Re: Improved HDCD information and logging

@ bonkers: you should probably check out the foo_hdcd thread on hydrogenaudio, where there is posted some issues (... godrick = you?)

Or, you could maybe write a script that traverses the directories and runs hdcd.exe -i on every file, sending exit codes to a log file. You don't have to interrupt ripping, of course -- do all ripping first, all HDCD scanning next, and then review your logs by searching for the exit code that indicates HDCD found.

Found one. Not checked whether it does what it says it does: http://forum.doom9.org/showthread.ph...00*post1247200

[bonkers]

Re: Improved HDCD information and logging

Porcus, I've reconsidered, and your argument is very persuasive! I forgot about Fb2k's output setting for bit depth which should be able to dither down to 16 bits any flac file regardless of whether HDCD was decoded when ripping or when playing, and not decoding HDCD for lossless files allows flexibility in later choosing hardware or software decoding, and makes any after-the-fact AccurateRip checking (like CueTools) still possible.

Is it correct to conclude that whether or not I used the HDCD DSP effect when ripping to a flac file, that the dBpoweramp accuraterip results when ripping will be unaffected?

And so for creating a lossy version, just to confirm: if I convert a flac file with encoded HDCD information, then I would need to select the HDCD DSP effect to ensure that any such HDCD effects are used when creating the lossy version?

That's not me in the hydrogenaudio thread, but now reading it it makes me wonder if the fb2k decoder is working correctly, and yet another reason to not decode HDCD into the saved file.

[Porcus]

Re: Improved HDCD information and logging

Is it correct to conclude that whether or not I used the HDCD DSP effect when ripping to a flac file, that the dBpoweramp accuraterip results when ripping will be unaffected?

Yes. AccurateRip is checked before applying any DSP's.

And so for creating a lossy version, just to confirm: if I convert a flac file with encoded HDCD information, then I would need to select the HDCD DSP effect to ensure that any such HDCD effects are used when creating the lossy version?

Yes.

That's not me in the hydrogenaudio thread, but now reading it it makes me wonder if the fb2k decoder is working correctly, and yet another reason to not decode HDCD into the saved file.

AFAIK, the hdcd.exe was constructed by reverse-engineering Windows Media Player (Microsoft bought HDCD in the nineties, so WMP supports it ... but not the transient filter), and the fb2k component is not completely identical anymore (see kode54's answer as of today).