Talk:High Definition Compatible Digital
|WikiProject Computing||(Rated Start-class, Low-importance)|
|WikiProject Professional sound production||(Rated Start-class, Low-importance)|
- Do not delete. Readers will search for both of those titles. Instead, one article should be replaced by a redirect to the other one. (I think it should actually be HDCD redirecting to the full name.) Andris 14:27, Aug 20, 2004 (UTC)
- Keep and redirect HDCD here. -- Grunt (talk) 22:47, 2004 Aug 20 (UTC)
- Keep. Agree, HDCD should be redirected to High Definition Compatible Digital. Nothing to merge that I can see. Andrewa 00:53, 21 Aug 2004 (UTC)
- Merge as necessary and redirect HDCD. -- Cyrius|✎ 01:13, 21 Aug 2004 (UTC)
- Use the article in HDCD as it is better worded, then redirect. Mandel 13:50, Aug 23, 2004 (UTC)
- Merge HDCD into this and make HDCD a redirect. -Sean Curtin 04:01, Aug 25, 2004 (UTC)
end moved discussion
"miniscule" reduction in range on normal CD player
Unless I'm missing something, shouldn't replacing the least significent bit with random numers (for the sake of a standard CD player, it is random) loose half the levels in the PCM signal?
I understand the difference wouldn't be obvious, but is loosing half the levels really a 'miniscule' drop?
WikianJim 17:08, 31 July 2006 (UTC)
- Yes. Ears have a logarithmic, not linear curve, so removing one bit from a 16-bit recording only decreases the sound quality by about 7%. This decrease is probably not audio unless a CD has really quiet passages; double-blind tests have shown that people can't tell the sound quality of a 14-bit CD from a 16-bit CD. Samboy 22:04, 8 January 2007 (UTC)
Link for the above please.
Bad premise: HDCD adds dither and encodes a very low bitrate control signal into the lsb, using the lsb of 1-2% of the samples as is documented in the refs F5r5e5d 16:43, 2 June 2007 (UTC)
- Is there a way to check on one's computer to see if it is equipped with a 24 bit card? J-Dog 01:40, 14 October 2006 (UTC)
== Hello, I haven't registered with Wikipedia yet, but I have edited this article. Before reverting, please consider the information I have edited. That is: - the technical explanation for how Microsoft somehow get an extra 4 bits of dynamic range into a regular uncompressed PCM signal. This defies the laws of mathematics! I personally dispute this claim. Funny how Microsoft have removed the info from their website. You can't add more dynamic range to a regular audio CD without this taking up more space - yet, HDCDs claim to do this!
- HDCD (when properly decoded) trades extra noise for extra dynamic range. In loud passages the noise floor will be higher, however this tends to be masked by the loudness of the passage.
- Note that it is the signal/noise ratio, not the dynamic range, which is limited by the bit-depth. With regular decoding the dynamic range is limited by the SNR, however with HDCD decoding it is not. 188.8.131.52 (talk) 00:58, 16 March 2009 (UTC)
Yes, too bad Microsoft removed the information.
I remember reading some documents from the original Pacific Microsonic site. The audio signal carried by an HDCD is actually compressed. If I remember well, the top 9dB of the dynamic range is processed using a 3:1 compression, reducing it to only 3dB. That means the rest of the audio signal is shifted upwards by 6dB. (I am not too sure about the ratio or the actual figures). When used with an HDCD compatible machine, the D/A expands this top 3dB, giving back the full 9dB dynamic range, with some extra bits to spare at the lower end of the signal.
The reasoning behind this is because the decibel scale is logarithmic (based on the human perception of sound). The top end of the dynamic range takes up most of the resolution in a linear PCM signal, and the engineers who invented HDCD seemed to think that it was unnecessary, therefore compressing the top range into a much smaller resolution scale.
Note that this is not "data" compression (as in MPEG schemes) but rather "dynamic" compression, something very similar to what Dolby or dBx have been doing with noise reduction schemes. This (no data compression) is because it would have rendered the disc logically incompatible with existing players. The aim for HDCD is to make available "better" CDs for ALL players. Regular players treat the signal as normal linear PCM. It's just that the curve actually used for digital conversion was not linear. Therefore the quality of the audio heard from these non-HDCD players is rather compressed (radio-like).
Perhaps HDCD was aimed for some genres of music such as jazz or classical, which generally does not compress the music before (even during) mastering. But pop/rock music has relied on dynamic compression, from the moment the sound is recorded up to the final mixdown. With current trends of loudness war (who gets the loudest music on CD), there is only about 3-6dB of dynamic range in those mixes. Those albums cannot really benefit from the claimed advantages of HDCD.
Since 2 or 3 years the HDCD processor in the mastering room I frequent has been left alone, a simple glance at it makes every engineer/client a shiver... if you know what I mean. Dulldull 09:54, 21 February 2007 (UTC)
Fair use rationale for Image:HDCD.jpg
Image:HDCD.jpg is being used on this article. I notice the image page specifies that the image is being used under fair use but there is no explanation or rationale as to why its use in this Wikipedia article constitutes fair use. In addition to the boilerplate fair use template, you must also write out on the image description page a specific explanation or rationale for why using this image in each article is consistent with fair use.
Please go to the image description page and edit it to include a fair use rationale. Using one of the templates at Wikipedia:Fair use rationale guideline is an easy way to insure that your image is in compliance with Wikipedia policy, but remember that you must complete the template. Do not simply insert a blank template on an image page.
If there is other other fair use media, consider checking that you have specified the fair use rationale on the other images used on this page. Note that any fair use images uploaded after 4 May, 2006, and lacking such an explanation will be deleted one week after they have been uploaded, as described on criteria for speedy deletion. If you have any questions please ask them at the Media copyright questions page. Thank you.BetacommandBot 06:37, 5 June 2007 (UTC)
Dither and transcoding
I would appreciate if someone knowledgable could address the following:
1. How exactly is the term "dither" used in this context? Does this refer to the whole concept of representing 'more' data (the extra dynamic range) using the various HDCD control codes (filter options, etc) across multiple CDDA frames -- so you get the dynamic range scaling and other tricks, just at slightly more than a per-sample timescale -- or does it refer to adding noise to the LSB of all samples so that any effect from the "< N%" of samples with control coding in the LSB aren't noticeable as some audible artifact amidst the garbage?
2. Presume that one has the equipment or ability to process a CD with HDCD encodings via software DSP and output the result as a 24-bit-per-sample PCM stream. Would rounding the 24-bit stream back to a 16-bit stream produce a "better" result for playback on conventional CD players? "Better" is obviously subjective, elaboration on what is lost/gained via this form of reencoding is welcome. —Preceding unsigned comment added by 184.108.40.206 (talk) 04:14, 5 January 2008 (UTC)
- 1. HDCD uses a noise-shaped dither when reducing the bit depth to allow signals below the noise floor to be represented (Similar to what is now used in practically all CD production, however when HDCD was invented it was a novel concept and one of the ways HDCD claimed to improve playback on non-HDCD players.) The control coding is incorporated into this dither in a way that isn't audiable, however the dither is not primarily designed to hide the control coding.
- 2. IMHO it would, depending on your definition of better of course. It will increase the dynamic range of most CD's since few utilise anywhere close to what straight 16bit LPCM allows. On the other hand, if the CD does utilise its whole dynamic range (e.g. some classical titles), then HDCD decoding->bit depth reduction may destroy some low level signals by pushing them below the noise floor. Also, in some listening situation, a reduced dynamic range may be desirable.
- It will also restore the peaks back to their original shape, resulting in less distortion. The loudness of the audio will be reduced, which depending on you stance may be a good or a bad thing.
- The relative noise level will be increased as a result of the loudness of the signal being decreased. IMO, the reduced distortion generally makes the recording more listenable desprite the extra noise. As noted above, this may destroy some low level signals. —Preceding unsigned comment added by 220.127.116.11 (talk) 05:41, 16 March 2009 (UTC)
HDCD also refers to High Definition Compact Disk, which is a regular CD-R or CD-RW burned in a DVD burner with a half-width laser track. The resulting disc is 1.4GB and is only readable in another DVD driver or better (HD-DVD or Blu-Ray)
Peak extend vs 'dynamic range extension' feature
Aren't these really just the same thing? The article makes them seem like separate features that the mastering engineer can control. —Preceding unsigned comment added by Krabapple (talk • contribs) 16:11, 11 March 2009 (UTC)
Windows Media Player and HDCD
According to the main article, WMP 10 and 11 no longer show the HDCD logo when playing. I'm playing an HDCD on WMP 11.0.5721.5260 right now and the HDCD logo is showing in the lower left corner. Perhaps somebody can do some more research on this? —Preceding unsigned comment added by Lothda (talk • contribs) 02:52, 5 June 2009 (UTC)
Reference source code
I also published the source code to my foobar2000 component on my site, which also includes the full source to the HDCD decoder itself. Of course, since I only gave the patent documents a cursory glance, I don't have a full explanation to certain things, such as all the floating point constants. Also, some other aspects, such as LFSR related variables, are not clearly labeled. I'm sure somebody interested in more than just getting the code to work could improve this.
Also, I don't buy this patenting issue when it comes to releasing the source. MP3 and other audio codecs are patented, but there are several patents covering them, and the developers of libraries which encode or decode these formats leave it up to the users of the libraries to deal with licensing the patents. Eh, whatever. Kode54 (talk) 17:32, 13 May 2010 (UTC)