My apologies in advance that the following is just as much questions on HDCD itself than of the component. Two brief component-specific inquiries first: (1) How do I apply the info tags? (2) There is no way to export info from report window? (Oh, by the way, it seems that quite some info given during these 11 pages, has changed along the way? Found the thread hard to read ... so hard I would volunteer to write a FAQ had I had any clue on the facts.)

So, I did a few years ago convert a lot of my (HD)CD rips into 24-bits using hdcd.exe before I was aware that decoding could be done on-the-fly. Now having scanned my entire lossless collection, I do have a few questions on the output (I used the current-as-of-today version 1.14), and then a few on interpreting data from my 24-bits files:

* I have a couple of CDs and at least one isolated track -- which report minimum gain = 0, maximum gain = 0, PE enabled and transient filter "Intermittent". Now I have no idea what the latter means, but is it so that the plugin does nothing about the transient filter at all (apart from detecting)? Various internet sources claim that no software decoder does.

* Quite a few of the HDCD tracks (including entire discs) have minimum gain = maximum gain = 0 dB, and both features reported to be "Disabled". These are the ones which have only been touched by a HDCD-enabled device, but not used any of the features? I.e., these should be regarded a "non-HDCD with extra noise in the LSB"? (And the plugin does so, when I have checked volume reduction to be applied only when P.E. enabled, right?)

* I found a CD where all tracks except one report gain 0, T.F. disabled, P.E. enabled -- and the exceptional track #2 reporting peak extension as "Intermittent". I can only guess that the entire CD is supposed to be treated equal? Or? How does the plugin react?

* There seems to be some difference between the component and the hdcd.exe utility, as one track which was skipped by the latter, was identified by foo_hdcd -- this on a CD which both of them agree, has both HDCD and non-HDCD tracks.

Then the 24 bits tracks:

* There are a few which peak at .5 or slightly below. Is this due to hdcd having halved volume on discs with no peak extension? Would these have been better off not coded over to 24 bits?

* Are there other values to look out for? (There are quite a few close to the square root of .5). Other signs so? For example, while peak scan shows that one end of the bitword is unused, is there any easy scan which will reveal it if the other end is unused?

The funny thing is that many so-called HDCDs (from my experience even most of them) don't have either of those features enabled, yet they are labeled as HDCD. But it only means that they were mastered on a HDCD capable device - they contain nothing that needs to be decoded.

They only contain the control bits that will cause the HDCD light on an HDCD capable player to lighten up, so people in audiophile internet forums can rant about how much better this or that album sounds on a HDCD player, not knowing that there's really no difference at all.

Now you should relax and make peace with your wife

The HDCD flag lets you know that the recordings was made with a PM-2 in the studio which many still believe is the best ADC ever made, it also means the mastering engineer was smart not to use the peak extend/gain/filter. There are also some technical arguments that a recording transferred with an ADC that has the same digital filter as the one you use at home has an advantage. Google PM2 mastered to study up on it if you are curious.

Well I am no expert but its all discreet even the converters. Purely engineering theoretical talk you can build an R2R discrete better than a chip as far as matching. But this is assuming that you agree R2R is a better means to and end that a 1 bit switcher. The other thing is the filtering, the PM engineers were a rare group that understood digital theory and had a solid background in analog sound engineering. If you search the web you can find some interesting info as far as the history and modern use by some of the top studio guys.

The funny thing about big business is the HDCD "gimmicks" like peak extend wre purely a marketing thing. I mean if a recording is mastered right you don't need peak extend. But the legacy is they gave the engineer who designed and built the PM ADC/DAC an unlimited budge to build a handful of the PM2's soley for the major sudios. And he didn't just take the easy way out, but did some real hard work and enginnering to build something that turned into a bit of a legacy. I almost bought one in 2001 for $8k, now you can't even touch one. If you are a top-dog studio with the connections you can borrow one, that says something.

* I have a couple of CDs and at least one isolated track -- which report minimum gain = 0, maximum gain = 0, PE enabled and transient filter "Intermittent". Now I have no idea what the latter means, but is it so that the plugin does nothing about the transient filter at all (apart from detecting)? Various internet sources claim that no software decoder does.

Nope, does nothing but report that the encoder used it.

QUOTE (Porcus @ Dec 16 2011, 07:37)

* Quite a few of the HDCD tracks (including entire discs) have minimum gain = maximum gain = 0 dB, and both features reported to be "Disabled". These are the ones which have only been touched by a HDCD-enabled device, but not used any of the features? I.e., these should be regarded a "non-HDCD with extra noise in the LSB"? (And the plugin does so, when I have checked volume reduction to be applied only when P.E. enabled, right?)

Correct, they use no features.

QUOTE (Porcus @ Dec 16 2011, 07:37)

* I found a CD where all tracks except one report gain 0, T.F. disabled, P.E. enabled -- and the exceptional track #2 reporting peak extension as "Intermittent". I can only guess that the entire CD is supposed to be treated equal? Or? How does the plugin react?

The default setting will halve the volume if P.E. is enabled, otherwise not. It probably means it was switched off at some point in the track, although it would need a full graph plot, or at least sample position ranges, to indicate where.

QUOTE (Porcus @ Dec 16 2011, 07:37)

* There seems to be some difference between the component and the hdcd.exe utility, as one track which was skipped by the latter, was identified by foo_hdcd -- this on a CD which both of them agree, has both HDCD and non-HDCD tracks.

This component only checks within the first 5 seconds or so of a track, otherwise ignores it.

QUOTE (Porcus @ Dec 16 2011, 07:37)

* There are a few which peak at .5 or slightly below. Is this due to hdcd having halved volume on discs with no peak extension? Would these have been better off not coded over to 24 bits?

hdcd.exe would always reduce the volume by half, whether or not the original track used any HDCD features, so peak would often be 0.5 or lower. The only extension which would change this would be Peak Extension.

My component defaults to doubling the output of the HDCD decoder unless P.E. is turned on. This can be changed in the Advanced section of Preferences.

QUOTE (Porcus @ Dec 16 2011, 07:37)

* Are there other values to look out for? (There are quite a few close to the square root of .5). Other signs so? For example, while peak scan shows that one end of the bitword is unused, is there any easy scan which will reveal it if the other end is unused?

Well, again, unless Peak Extension or Low Level Adjustment are enabled, then the least significant bits won't be used either. It does not attempt to undo the dithering into more resolution than there was in the original signal. So while there may be perceptibly more signal room due to dithering, there is no actual information below the 16 bits of the input signal unless either of those two features is used.

thanks for the "customer" support (and for maintaining the thing). Now I played around a bit with the component, and with the hdcd.exe utility on the CD where there was one "intermittent" peak extension (the CD is Clawfinger: s/t). There are some odd results:

(1) hdcd.exe: Does not detect HDCD on any of the tracks. Maybe due to not scanning the entire track?(2) your component scanning FLACs: first track "intermittent" peak extension, 9 of the remaining 11 tracks "enabled" (last two not showing any sign of being HDCDs).(3) I then convert the FLACs from point (2) to WAVs and verify that they are bit-identical, and run your component on these. Result: one more track (#2) showing up as "intermittent" in addition to track #1. (Other tracks as in (2).)(4) I am not sure how to use your component to encode a HDCD -- I suspect I have to set bit-depth manually? Anyway, I enabled post-processing and converted the WAVs to FLAC. Result was 16-bit, but different from the original, so I suppose I did manage to apply the HDCD decoding. But even then, four tracks (## 3, 4, 6, 10 -- i.e., none of the troublesome "intermittents" from the outset), report as Peak Extension "Enabled".

(1) hdcd.exe: Does not detect HDCD on any of the tracks. Maybe due to not scanning the entire track?

It detects nothing, or it detects nothing useful? If the former then you may have got something in your FLAC decode process which messes up the HDCD signalling. If you used Fb2k then you might want to switch off dither.

(4) I am not sure how to use your component to encode a HDCD -- I suspect I have to set bit-depth manually?

Where you say "encode a HDCD" I assume you mean that you want to convert HDCD input into 24-bit PCM output.

As I recall, you declare the encoder (being FLAC or WAV output) as being 24-bit. Fb2k is floating-point internally, and components like this aren't going to change any explicit bit depth on the data path.

This seems more and more like a bug -- versions 1.12 and 1.14 differ in behaviour:

In a posting above, I described a case where "Scan for HDCD" yields peak extension- "Enabled" on file.flac- "Intermittent" on file.wavand for the record, they verify as identical using foo_bitcompare.

I just checked this with another computer which used version 1.12, and the issue was not present. Upgraded to 1.14 and applied changes to (= restarted) fb2k, and problem reproduced on that other computer. So, problem seems to be introduced in 1.13 or 1.14. (Both fb2ks were current version 1.10.)

Also, to clarify:

QUOTE (Porcus @ Dec 18 2011, 21:45)

(1) hdcd.exe: Does not detect HDCD on any of the tracks. Maybe due to not scanning the entire track?

I am interested if there are any HDCD encoders that can be added in foobar. If I am playing a 24bit, 88.2kHz (native) file, to be able to convert it to a HDCD 16bit, 44.1kHz with both extensions enabled (to play at 20bit level in my universal DVD player or in my receiver - the WDTV Live that I use doesn't pass over SPDIF the 88.2k files, just the 96k ones).

I apologize if this info has already been posted but right now I don't have time to read all 10+ pages of posts, but in experimenting with this, trying to get it to work on a CD rip that I *knew* was HDCD (Tool - Lateralus - 2001), I could not get it to work on FLAC, WAV, using CUE, no CUE, etc.

I had disabled all DSP's and ReplyGain as mentioned, but it still kept saying invalid files or no valid files found.

I found the problem that foobar was reporting these as WAV files (they are Windows .WAV format files)... but I noticed without using the CUE sheet, it reported the WAV file as merely PCM. So, I found this interesting; I went into the CUE file and changed the type after the filename from WAVE to AIFF (this was ripped SINGLE IMAGE+CUE) and I then encode to FLAC and embed the CUE and art.

It now showed all files (when loading the CUE file, which obviously, here, references the indexes in the single WAV image, it reports them as PCM, and the plugin works (albeit it only works on the current file playing when using the variables %hdcd%, etc). Not sure if that is intended or something I'm doing wrong.

Any insights into why this was a problem? I know (at least I believe I know) that the main difference between WAV, PCM and AIFF is basically that WAV is a "Windows" format primarily, whereas AIFF is Mac's preferred format... PCM is like raw audio date, but I *thought* it was equivalent to WAV format... "WAV=PCM"; I know also that WAV (supposedly) cannot hold any tagging data, while AIFF can.

One last question, when using CUETools, there's an option to encode HDCD detected stuff to 24-bit lossless files (FLAC) (which it really plays back as 20-bit, which I understand that is all that HDCD is, anyway...).

I do understand some detailed audio information, such as Nyquist's theorum (to accurately duplicate audio it has to be double the highest + 1 at minimum-- therefore 44,100Hz has to go to say, for example... 89,000Hz and some extra at very minimum for the dB)-- which is what the half the volume has to do with, I trust... which is the vertical axis... whereas the horizontal is split up to certain periods, called samples... and the higher your sampling rate, the smaller your samples will be, and the higher your accuracy will be...

But 16-bit tracks will output up to like 96dBHL or 98dBHL; which I have read is pretty much more than your average stereo system/speakers can reproduce anyway, making the 20-bit/24-bit idea pretty superfluous? 20 or 24-bit goes to 120dBHL or more, (vague recall... this is all just from my head)... but furthermore, this 20/24-bit data is actually stored WITHIN a 16-bit depth digital waveform by some form of using higher frequency hackery to store this, or using data below the human threshold (like 10Hz, for super sure... I know 20Hz is average, but in lab studies they've shown that ppl, esp young children can hear down to 16Hz or 12Hz). Don't worry about answering anything regarding the dynamics of HDCD, I already saw some posts with links to detailed info on HDCD above, so I'll have those to read. (Thanks for the links!)

Insights/corrections? I think I probably need to go re-study the difference between a WAVE file and a PCM file, because I was under the impression that there was no difference -- but if this were true, then changing the file type in the CUE from WAV to AIFF wouldn't have made any difference to the plugin...?

Gotta run, but I'll be sure to read through this whole thread and some more when I get the extra time. Thank you all for reading/any responses!

P.S. Just read this while closing out this tag, saw this in my search results:

QUOTE

First, WAV and AIFF are almost exactly the same thing. They are both containers for RAW PCM audio. The only difference is that WAV originally was a Microsoft / IBM standard and AIFF originaly was an Apple standard. They both will preserve the resolution of the CD PCM audio perfectly and untouched. The downside is that the size of the files will be exactly the same as it was on the CD and thus very large (about 10MB per minute of CD audio).

I understand this, though... as I sort of explained earlier... I'll look further into the CONTAINER formats though since this says for a fact (hopefully... I didn't know for a FACT that PCM was actually just the RAW data inside WAV container... or that WAV was indeed actually a container, since it didn't support tagging; I would have figured AIFF would be a container more than WAV... anyways, enough... GG)

I am interested if there are any HDCD encoders that can be added in foobar. If I am playing a 24bit, 88.2kHz (native) file, to be able to convert it to a HDCD 16bit, 44.1kHz with both extensions enabled (to play at 20bit level in my universal DVD player or in my receiver - the WDTV Live that I use doesn't pass over SPDIF the 88.2k files, just the 96k ones).

I read somewhere that the reason for this is that 88,200Hz <-> 44,100Hz conversion is not as simple or "accurate" of one because of floating point math being used? It said that using 48,000Hz source was much better and more accurate because of the frequency conversion over directly to 96,000Hz was "easier/better". So, having said that... could you try having it use 48,000Hz and then resample it/downsample to 44,100Hz?

Tool - Lateralus does not use any noticeable HDCD features. It does use the gain level reduction at the very beginning of the first track, but only during a region of digital silence. The rest of the CD has all features disabled, so the output should be identical to the input.

OK, but what is done with the signal at all when there's no peak extension enabled? I examined some tracks with foobar and the bit comparison did show some minor differences (~0.01% of the samples), though the peak values were unchanged and I didn't ever bother to try to ABX the tracks.

QUOTE (kode54 @ Sep 12 2011, 02:42)

There should be no difference at all if the volume isn't being halved and there's no peak extension. The signal is otherwise passed through unmodified, except for the conversion from and back to float.

QUOTE (Northpack @ Sep 12 2011, 02:46)

So the differences are most likeley due to rounding error, I guess. But what about this low level extention stuff?

I'm not sure if this is the correct place to address this or not, but...how is the 6dB reduction (regardless of HDCD content) accomplished? I've been doing some comparisons between the original 16-bit audio and the HDCD decoded 24-bit audio, and my concern is that there seems to be a low level signal (dither?) present beyond what is expected for Peak Extension and Low Level Extension (the latter which is quite obvious on the tails of fades). This low level signal is present whether or not the input was HDCD encoded.

Shouldn't HDCD.exe just be doing a bit shift to reduce the level by 6 dB? And then applying PE and LLE where applicable?

This is how I've been looking at things:

1) Load both files in Audacity.2) Reduce level of original file by 6dB.3) Invert original file.4) Export the combined result and analyze.

I'm using 32-bit float within Audacity. Now, I have a feeling there may be some rounding happening in Audacity rather than a simple bit shift, but even so, the above process is resulting in greater low level signal than essentially doing the same thing in Audacity - leaving one file untouched and adjusting the other down by 6 dB and then back up by 6dB.

The main volume change in this decoder is a bit shift, while the low level extension is in half decibel increments.

Ok, thanks. I just tried a null test in Audacity, adjusting the undecoded files by -6.020599913 dB instead of -6 dB, and that does seem to effectively null out everything except the effects of PE and LLRE.

Greetings! Thanks for providing this wonderful component to the community, I just discovered it yesterday and it works great!

However, I have one small problem - when I try to convert ape to flac, it seems that HDCD encoding is lost in the process. If I convert to 24-bit, it's gone all the way - however, if I convert to auto or 16-bit, HDCD flag is on for first 10 seconds of the converted track and then it disappears! Any idea what I am doing wrong?

Kode54: I refer to the posting below. Looks like I no longer have any 1.12 version. Are there anywhere old versions available, which I can use for testing?

QUOTE (Porcus @ Dec 30 2011, 16:01)

This seems more and more like a bug -- versions 1.12 and 1.14 differ in behaviour:

In a posting above, I described a case where "Scan for HDCD" yields peak extension- "Enabled" on file.flac- "Intermittent" on file.wavand for the record, they verify as identical using foo_bitcompare.

I just checked this with another computer which used version 1.12, and the issue was not present. Upgraded to 1.14 and applied changes to (= restarted) fb2k, and problem reproduced on that other computer. So, problem seems to be introduced in 1.13 or 1.14. (Both fb2ks were current version 1.10.)

Also, to clarify:

QUOTE (Porcus @ Dec 18 2011, 21:45)

(1) hdcd.exe: Does not detect HDCD on any of the tracks. Maybe due to not scanning the entire track?