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: Another HDCD thread... (Read 13931 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Re: Another HDCD thread...

Reply #25
In this case a software decoder needs decode to a higher sample rate (e.g. 2x) for the transient filter to work.
To mimick the oversampling in the DAC?
Pacific's HDCD decoder defaults to 8x oversampling, it seems: http://tech.juaneda.com/download/PMD100.pdf

Re: Another HDCD thread...

Reply #26
Many DAC chips apply filters in cascaded form (e.g. 2x2x2). For example, if the input is 88.2/96k one filter stage would be skipped, so only 2x2 and 176.4/192k would be x2.

Because typical DAC chips still oversample when receiving 88.2k input, a software decoder only needs 2x to justify the minimum required implementation of the transient filter.

Modern chips usually work in this way:
input -> 8-16x FIR filter -> 64-1024x lower quality filter (e.g. ZOH, LERP) -> modulator -> DAC -> analog filter -> output

Re: Another HDCD thread...

Reply #27
Looks like I can make a 20-bit file with SoX.

Code: [Select]
sox input_hdcd.flac -b 24 output_20b.flac dither -p 20
This means dither to 20 bits, because SoX uses a traditional approach (contrast to e.g. Case's smart dither), the LSBs will always be filled, even when the input is digital silence (all zero).
The commands below truncate any 24-bit input file to 17-23 bits without dither. Try to compare file size between HDCD decodes and normal 24-bit files. -D disables automatic dither. SoX by default applies no dither if output bit-depth >= 24, but IIRC a 3rd party compile I used still dither with 24-bit output.
Code: [Select]
sox 24bit.flac 17bit.flac" -D vol 3.0517578125e-5 vol 32768 stats
sox 24bit.flac 18bit.flac" -D vol 6.103515625e-5 vol 16384 stats
sox 24bit.flac 19bit.flac" -D vol 1.220703125e-4 vol 8192 stats
sox 24bit.flac 20bit.flac" -D vol 2.44140625e-4 vol 4096 stats
sox 24bit.flac 21bit.flac" -D vol 4.8828125e-4 vol 2048 stats
sox 24bit.flac 22bit.flac" -D vol 9.765625e-4 vol 1024 stats
sox 24bit.flac 23bit.flac" -D vol 1.953125e-3 vol 512 stats

All software decoders we have today can only do up to 223, but not 224.
https://patentimages.storage.googleapis.com/4f/ea/aa/7bb5490b83807a/US5479168.pdf
X
Quote
The data signal then goes to delay module  222, which gives the control decode module 221 time to figure out what to do with the signal before it gets to the first DSP subsystem 223. The first DSP module 223 is the complement to module 210 in the encoder. It does a peak expansion which restores the peaks limited in 210. It does a low level gain expansion, restoring the low level dynamics compressed in 210. It can complement the low level forcing of high frequencies in the dynamic dither operation, restoring a flat frequency response and lowering quantization noise. It performs some house keeping functions, and its signal output has 18 to 20 bits of real information at the one-times sampling rate (44.1 kHz for CD).

This more accurate digital signal at the media sampling rate is routed to the second digital signal processor sub system 224, which is complementary to encode module 205. In this subsystem, the signal is interpolated to a higher sampling rate using a variety of smoothing filters which are chosen to complement the decimation filters in 205.

Re: Another HDCD thread...

Reply #28
In my quest to deal the HDCD tainted CDs, I found that I need to enable ReplayGain in resultant hdcd.exe decoded files to compensate for the relative overall -6 db 'loss' in the resulting output when compared to the original 16 bit input.  Without ReplayGain, those decoded files require a significant volume boost when played back when compared to the playback of the original.  I imagine that HDCD capable CD players and DACs also automatically apply a ReplayGain of sorts to compensate for that same HDCD decoded 'loss', at least that's what my Pacific Microsonics equipped CD player seems to do with HDCDs.  Surprised that that 2005 player still works, though nowadays I use it as a transport for most of my CDs.

Re: Another HDCD thread...

Reply #29
I'm NOT an expert on this...

If you are already using ReplayGain it would make sense to simply keep using it.   But that doesn't restore the HDCD peaks & dynamics.   

You could also used Audacity to boost the digital level, or some players like VLC allow you to turn the volume up over "100%".  But again, that doesn't "decode" the HDCD data.

Quote
I imagine that HDCD capable CD players and DACs also automatically apply a ReplayGain of sorts to compensate for that same HDCD decoded 'loss', at least that's what my Pacific Microsonics equipped CD player seems to do with HDCDs
It decodes the HDCD and restores the peaks.   That may, or may not, make it "louder" depending on the dynamics of the recording.

Re: Another HDCD thread...

Reply #30
I imagine that HDCD capable CD players and DACs also automatically apply a ReplayGain of sorts to compensate for that same HDCD decoded 'loss', at least that's what my Pacific Microsonics equipped CD player seems to do with HDCDs.
It just plays regular CDs 6 dB quieter to match the 6 dB decrease from HDCD decoding.

Re: Another HDCD thread...

Reply #31
The commands below truncate any 24-bit input file to 17-23 bits without dither. Try to compare file size between HDCD decodes and normal 24-bit files. -D disables automatic dither. SoX by default applies no dither if output bit-depth >= 24, but IIRC a 3rd party compile I used still dither with 24-bit output.
Code: [Select]
sox 24bit.flac 17bit.flac" -D vol 3.0517578125e-5 vol 32768 stats
sox 24bit.flac 18bit.flac" -D vol 6.103515625e-5 vol 16384 stats
sox 24bit.flac 19bit.flac" -D vol 1.220703125e-4 vol 8192 stats
sox 24bit.flac 20bit.flac" -D vol 2.44140625e-4 vol 4096 stats
sox 24bit.flac 21bit.flac" -D vol 4.8828125e-4 vol 2048 stats
sox 24bit.flac 22bit.flac" -D vol 9.765625e-4 vol 1024 stats
sox 24bit.flac 23bit.flac" -D vol 1.953125e-3 vol 512 stats
The orphaned quotation mark of course is a mistake, but hopefully people who familiar with console apps already know that quotes should be used when the paths contain white spaces.

Re: Another HDCD thread...

Reply #32
That said, the 20 bits could have come from the advertising bragging.
From hardware perspective, 20-bit could have been chosen due to availability/cost/performance concern 20-30 years ago.

The Pacific handled 24 bits. HDCD encoding was part of the downmix from 88.2/24 to 44.1/16.
It also handled 20 bits, though.
Looks like it is more appropriate to reply on this thread. Just did a quick search on HDCD players/decoders (so, decoding and consumer side) and I found this:
https://www.audiosciencereview.com/forum/index.php?threads/audio-alchemy-dde-v3-0-quick-measurements.7558/
The results are surprisingly bad:
Quote
THD+N of -74dB, DR of 74dBA. Not great. Good size spikes at 60Hz and 180Hz and that's with an upgraded power supply (PS-2). Harmonics are fairly high in level, and seem to not go down by much with increasing frequency. That's bad.
Just for comparison here is my DAC measurement of a 1995 MD walkman. MD recorders often offer a recording monitor mode taking SPDIF input to analog output without actually recording anything on the disc, so there is no lossy compression involved.
https://www.audiosciencereview.com/forum/index.php?threads/zoom-f6-portable-field-recorder-review.15668/post-504924


Re: Another HDCD thread...

Reply #34
Another indication that 16-bit audio is actually enough, when used properly. If apparently nobody really noticed, I'd say HDCD was mostly a gimmick so people could be lured in with a loud master, while defending the practice to purists as HDCD could fix it.
Music: sounds arranged such that they construct feelings.

Re: Another HDCD thread...

Reply #35
Being cynical: In a market that demanded 3 dB dynamic range, it wasn't necessarily the worst that could have happened. Easy to write it off now 29 years later, but ... compared to SACD?

As for the "16 is enough": In those 19.2 dB that HDCD touted - then conveniently rounded up to 20 - then around 1.7 dB would be the PE and LLE, wouldn't it? So 1.5 of those bits do not require HDCD decoding, those are from their downmix from 88.2/24. Sounds like a cheat in the marketing, but it did a job that was supposed to be done properly - and that was nearly as much as the encoding/decoding part of the format.

Re: Another HDCD thread...

Reply #36
When a certain technology exists, people will abuse it. While CDDA is a 80s technology, a lot of intermediate processing stages were still being done in analog. In the 90s digital audio technology has been evolved to allow more affordable digital processing stages, with dynamic range compression being one of them. So, while HDCD can be seen as one of the culprits of the loudness war, even if it does not exist in history, there were still other means for digital dyanmic range compression in that era.

SACD of course has other forms of marketing hypes and lies, but at least the encoding scheme (DSD) is non-proprietary and there are several free of charge and FOSS encoders avaliable, so that others can gauge the performance more easily.

 

Re: Another HDCD thread...

Reply #37
My 18 years old Denon DCM-390 HDCD capable cd player recently gave out, due to a failure of its carousel drive motor.  This failure was unfortunate in both that the playback electronics are still working fine, and that two discs were trapped inside it.  Pulling its case to recover the discs also revealed that it uses a Burr Brown (TI?) PCM1732 DAC chip in which the HDCD functionality was completely "built in".  That "hybrid" is curious to me to say the least (as a complete noob).  Its SNR is given as 104 dB for decoded HDCD playback, was that typical for HDCD? .

With the demise of this player, I now regret owning a few RR HDCDs that I knowingly purchased.  I now see HDCD as one of those "just because you can doesn't mean you should" sort of things.  All that's left is to deal with its sorry legacy (hdcd.exe anyone?).  BTW, that player was not the first HDCD player I owned.

Re: Another HDCD thread...

Reply #38
See for example the results of a product using Burr-Brown PCM-63 in Reply #33, which advertised 20-bit with -96dB THD+N 116dB SNR, and how the actual measurements differs (-88dB THD+N). It was measured using Apogee Element 24 and its ADC performance is not a bottleneck:
https://www.audiosciencereview.com/forum/index.php?threads/apogee-element-24-thunderbolt-interface-quick-measurements.7522/
It is not uncommon to find such discrepancies between chip specs and measurement results as the whole product.

Another tricky thing is SNR and DNR (dynamic range), they are different measurement metrics:
https://www.ap.com/news/signal-to-noise-ratio-snr-dynamic-range-and-noise

Specifically, dynamic range is measurement of THD+N using a -60dBFS test tone, the purpose is to prevent some devices shut down the output completely when there is no input and resulting an unrealistically low noise level. Another reason is some devices may exhibit idle noise (low level high frequency tones) when the input signal is suddenly muted. The presence of a -60dB test tone prevents it to happen.

Are there 90s DACs with HDCD capability exceeding 16-bit analog performance? Here is one example, not cheap, and it does not have a CD transport:
https://www.audiosciencereview.com/forum/index.php?threads/mark-levinson-no-360s-dac-review.10842/

Re: Another HDCD thread...

Reply #39

I wanted to see a visual of what the different is between the original audio and the audio after decoding with the HDCD filter.  The filter lowers the gain by -6dBFS, and outputs to 24-bit WAV.  I used ffmpeg to apply the filter, and to draw the waveforms.  The waveforms are the original audio (orange, lowered by 6dBFS) over the decoded waveform (light orange).

This is the track "Blue Monday" that does use Peak Extend.



This visual seems odd to me.  Of the HDCDs I own, a subset* use 'peak extend'.  On those, the undecoded waveform looks slammed, in a loudness wars fashion -- multiple peaks at 0dbFS.  The decoded version has a more dynamic, 'audiophile'-like waveform, just one or few peaks at 0dBFS.  Visually, the waveform difference is striking.

If I interpret Replica9000s visual correctly, the light (decoded) version shows many, many peaks at maximum level, while the dark orange (undecoded) does not.  This looks exactly backwards to me.

Could be I'm reading this wrong.  Showing it as light orange/dark orange overlaid doesn't help, It's not easy for me to tell them apart.  Separate waveforms for decoded/nondecoded might be more clarifying.


* for the rest, all decoding does is lower the level by ~6dB.  The waveforms are otherwise identical.

 



Re: Another HDCD thread...

Reply #40
(and yes, I was aware that the nondecoded has been manually lowered 6dB.  Which adds to my confusion.    Separate waveforms, unretouched, would help. )

Re: Another HDCD thread...

Reply #41
These are the commands I used to make the separate waveforms. 
Code: [Select]
ffmpeg -i blue_monday_orig.wav -lavfi showwavespic=split_channels=1:filter=peak:s=1600x800:colors="#E17400" blue_monday_orig.png
ffmpeg -i blue_monday_orig.wav -af hdcd -c:a pcm_s24le blue_monday_hdcd.wav
ffmpeg -i blue_monday_hdcd.wav -lavfi showwavespic=split_channels=1:filter=peak:s=1600x800:colors="#E17400" blue_monday_hdcd.png

Original Audio - No alterations.
X

Audio after decoding with HDCD filter
X

Here's a screenshot of the two waveforms in Audacity
X


Re: Another HDCD thread...

Reply #42
Well even the decoded version there has rather, um,, 'modern' mastering.   Though the effect is visible, with the central axis getting 'skinnier'.  Not sure what those random spikes are.

My experience with apparently effective Peak Extension has been more like this (undecoded top, decoded bottom; to compare them more fairly the bottom was minorly normalized by +0.5dB to peak at 0dbFS, the top was already there):