support HDCD

[Christoph Anton Mitterer]

Hey.

(Thought I'd have reported that here before, but I cannot find the ticket anymore)

AFAICS, ffmpeg does not support HDCD content (i.e. CD-DAs that use that encoding or WAVs extracted from such CD-DAs and in which the necessary data should still be present).

Even though HDCD is a dead format now (well more or less, according to some source there are allegedly still up to 4k titles available... not much) it would be nice if a decoder could be added, since people have CDs respectively rips thereof in this format and it would be nice if they have a way to listen to it even in 20 years or so.

Apparently there is source code for a decoder available under an open source license, so that might be taken and adapted as necessary:
​https://github.com/kode54/foo_hdcd

Many information about HDCDs is floating around the web, e.g.:
​https://forum.dbpoweramp.com/showthread.php?27540-Ripping-HDCDs-Best-practices

In any case note, that HDCD doesn't only apply to CDs (as mentioned above).
Further, it's apparently the case there are several features in HDCD (some of this is explained above) and that just the stream indicator for "HDCD encoding present" alone doesn't tell much...
Also it and the features as well can vary from track to track.

Best wishes,
Chris.

[Carl Eugen Hoyos]

Please provide a sample.

[Christoph Anton Mitterer]

Well the problem is a) that I'm still looking for samples in my own collection, and b) all of them are quite likely copyrighted, so it's a bit problematic to simply post them here.

Maybe that one of the first post can be used:
​​http://www.hydrogenaud.io/forums/index.php?showtopic=108645

But I don't know now, which of the HDCD features (basically PE and LLE) are used by that sample.

[Carl Eugen Hoyos]

This feature request only makes sense if you can provide a sample that you ideally tested yourself.
(I don't think many of the thousands of samples in our collection are not copyrighted.)

[Christoph Anton Mitterer]

Well the sample above seems to work... "tried myself" is here probably useless,... HDCD is like some Dolby codecs, i.e. you can play it just fine even without a decoder, but you loose something.
And I personally am definitely not audiophile enough to be sure that I really could tell the difference. ;-)

Apart from that, I think the code from foobar2000 can probably seen as kind of a finished implementation.
I've read through many forums now and that seems to be the conclusion.
There is that infamous "transient filter" feature, but having talked to some experts, this was never ever used in HDCD and there was always only one filter in decoding.

[Carl Eugen Hoyos]

This isn't about being audiophile or not: The feature will not be ported to FFmpeg if no file exists that can be used for testing. I suspect most (all) FFmpeg developers cannot test foobar2000 (and it takes time that could be used to implement other features), so please provide a sample.

[Christoph Anton Mitterer]

So what's wrong with the samples provided in the link above? Can these be used or do you need more?

[Carl Eugen Hoyos]

Why didn't you attach the samples here?

Unfortunately, I don't understand the samples: I would have expected one file that contains s16 data and one that contains s24 (or s32) data to be able to compare the original wav file that contains the HDCD information and the (output) file with the HDCD "conversion" applied.
Apparently, I completely misunderstand: Can you explain?

[Carl Eugen Hoyos]

Are you still interested in this feature?
If yes, please answer my comment:7 and/or upload the output when processing the file(s) I attached with foobar2000 and the HDCD plugin.

[Christoph Anton Mitterer]

My problem right now is that I'm still looking for a working HDCD sample.

The one attached above may not be HDCD (I tried to "decode" it with the well known hdcd.exe) but it doesn't detect HDCD there.

I think I have only one HDCD CD myself, I'll look into that whether something from there can be used.

[Carl Eugen Hoyos]

Can you confirm that hdcd.exe produces output for input from your HDCD CD but not for the samples attached in the hydrogenaudio forum?

[Carl Eugen Hoyos]

I meant:
Can you confirm that hdcd.exe reports a HDCD input for a wav file ripped from your sample CD? It does not show HDCD info for the attached files afaict.

[Carl Eugen Hoyos]

I attached two samples.

[cyclonus]

Jim Lesurf has written some information about HDCP on his homepage:
​http://www.audiomisc.co.uk/HFN/HDCD/Enigma.html

He has also written misc. audio software:
​http://www.audiomisc.co.uk/software/index.html

Here he provides the source code for a HDCP decoder:
​http://www.audiomisc.co.uk/software/WAV_HDCDexpander.tgz

I've successfully compiled PlainVersion.c after some minor 64-bit fixes i.e. I had to replace "long" with "uint32_t" in the three structs (wav_header, wav_format, wav_data) for obvious reasons.
I compiled it as follows:

cc -W -Wall -Wformat=2 -O2 -lm -o hdcd PlainVersion.c

The resulting executable takes the input file as first and output file as second argument.
Next, I've ripped the only HDCD I own with cdparanoia and converted all WAV files with
the hdcd tool. Apparently it recognized HDCP information in all tracks.

It seems because the output is a "legacy WAVE" file, mplayer didn't want to play them as 24-bit files. After converting them to FLAC "ignoring WARNING: legacy WAVE file has format type 1 but bits-per-sample=24", they are played as 24-bit files without downsampling to 16-bit.

The HDCD-decoded files sound different but, of course, I have no way to tell whether that's what they're supposed to sound like.

Further, I tried the same with a normal audio CD. No HDCP information was detected.

Last, I've also downloaded the sample files HDCD32.flac and HDCD16.flac and converted them both to WAV. The tool correctly detects HDCD information in HDCD16.wav. The output is identical to HDCD32.wav - except for header.cksize (3 bytes in the header).

[Carl Eugen Hoyos]

Replying to cyclonus:

​http://www.audiomisc.co.uk/software/WAV_HDCDexpander.tgz

This looks proprietary. Did you ask the author if this was his intention?

Next, I've ripped the only HDCD I own with cdparanoia

Please provide a (short) sample.

[Christoph Anton Mitterer]

Apparently it's open source, there's a license included in the tarball...
It seems to be based on the foobar hdcd which I've mentioned in the original report.

Cheers,
Chris.

[cyclonus]

Sample before HDCD decoding

[cyclonus]

Sample after HDCD decoding

[cyclonus]

License statement

[cyclonus]

Sorry, I would've replied earlier, if I had received any e-mail notification.

For what it's worth I had to resort to 'dd' for creating a short sample. The fine tool 'Audacity' corrupts audio samples - at default settings - even when loading a WAV file and exporting it as WAV file. The resulting file didn't contain any HDCD information due to the modified samples.

The HDCD utility provided was apparently written by Chris Moeller (author of Foobar), Nick Gorham and Jim Lesurf. The license statement from the tarball is attached.

[Carl Eugen Hoyos]

Replying to cyclonus:

Sorry, I would've replied earlier, if I had received any e-mail notification.

Just add your user name to CC

The HDCD utility provided was apparently written by Chris Moeller (author of Foobar), Nick Gorham and Jim Lesurf. The license statement from the tarball is attached.

You attached the license of the original code that the code you used was based on. The original license allows everybody to "use" the code in any way, including to write a proprietary (non-free) application. The new code (the one you used) contains no license statement, it is therefore not free software (at least where I live, public domain does not exist, and I did not find any hint that the author wanted his code to be free software). The only restriction in the original license is that if the source code is distributed, the original copyright notices must not be removed, It seems to me that the author violated this restriction or do I miss something?

[cyclonus]

It seems I can only CC my e-mail address which is then public in the ticket. Not cool.

I've e-mailed the author to clear up the license situation.

[Carl Eugen Hoyos]

Implemented in 0cfe16437fce4c2090d39552cf63d559c139f06d

[Christoph Anton Mitterer]

Awesome :-)

Thanks to all people involved in making this happen!

[Christoph Anton Mitterer]

Perhaps one might want to change the documentation from current:

Decodes high definition audio cd data. 16-Bit PCM stream
containing hdcd flags
is converted to 20-bit PCM stream.

to:

Decodes High Definition Compatible Digital audio data. 16-Bit > PCM stream containing HDCD flags
is converted to 20-bit PCM stream.

• "High Definition Compatible Digital" seems to be the official meanting of the acronym.
• HDCD is not really Audio CD specific, so IMHO one can drop that reference.

[Carl Eugen Hoyos]

Feel free to send a patch made with git format-patch but imo hdcd is cd-specific.

[bp0]

There is no documentation, how is this used?

$ ffmpeg -i HDCD16.flac -af hdcd OUT.wav

ffmpeg version N-80801-gc0cb53c Copyright (c) 2000-2016 the FFmpeg developers
  built with gcc 5.3.1 (Ubuntu 5.3.1-14ubuntu2.1) 20160413
  configuration: --enable-libfdk-aac --enable-nonfree
  libavutil      55. 27.100 / 55. 27.100
  libavcodec     57. 48.101 / 57. 48.101
  libavformat    57. 40.101 / 57. 40.101
  libavdevice    57.  0.102 / 57.  0.102
  libavfilter     6. 46.102 /  6. 46.102
  libswscale      4.  1.100 /  4.  1.100
  libswresample   2.  1.100 /  2.  1.100
Input #0, flac, from 'HDCD16.flac':
  Metadata:
    ARTIST          : Laura Nyro
    DATE            : 2000
    GENRE           : Folk
    TITLE           : Wedding Bell Blues
    ALBUM           : Time And Love: The Essential Masters [2010 Audio Fidelity HDCD AFZ 085]
    track           : 02
    ENCODER         : Lavf56.31.100
  Duration: 00:00:20.00, start: 0.000000, bitrate: 932 kb/s
    Stream #0:0: Audio: flac, 44100 Hz, stereo, s16
[wav @ 0x32a4d80] Using AVStream.codec to pass codec parameters to muxers is deprecated, use AVStream.codecpar instead.
Output #0, wav, to 'OUT.wav':
  Metadata:
    IART            : Laura Nyro
    ICRD            : 2000
    IGNR            : Folk
    INAM            : Wedding Bell Blues
    IPRD            : Time And Love: The Essential Masters [2010 Audio Fidelity HDCD AFZ 085]
    IPRT            : 02
    ISFT            : Lavf57.40.101
    Stream #0:0: Audio: pcm_s16le ([1][0][0][0] / 0x0001), 44100 Hz, stereo, s16, 1411 kb/s
    Metadata:
      encoder         : Lavc57.48.101 pcm_s16le
Stream mapping:
  Stream #0:0 -> #0:0 (flac (native) -> pcm_s16le (native))
Press [q] to stop, [?] for help
size=    3446kB time=00:00:20.00 bitrate=1411.3kbits/s speed= 348x    
video:0kB audio:3445kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: 0.006973%

The output is also 16-bit, although a little quieter.

The windows-only binary hdcd.exe that floats around has this to say about HDCD16.flac (after flac -d)

HDCD Detected
Decoding Statistics:
  Packets Processed              : 231
  Peak extend                    : Never enabled
  Minimum gain                   : 0.0dB
  Maximum gain                   : 0.0dB
  Transient filter (Unsupported) : Enabled intermittently

[Carl Eugen Hoyos]

The wav muxer defaults to pcm_s16le, if you want FFmpeg to use another codec (like pcm_s24le), you have to specify it with the acodec option.
Please understand that this is not related to the hdcd filter and please post all usage questions to the user mailing list.

[Christoph Anton Mitterer]

Mhh if HDCD is detected (is the patch here capable of auto-detection?), wouldn't it make sense to have ffmpeg automatically default to 20bit (or was it 24bits?)?

[bp0]

Re: calestyo; ba69a81019a2642969b108c39e3bea7d2f8ffbfa
The docs are updated and include the correct name of HDCD. Also, there was a bug in the low-level gain adjustment that is fixed.
The filter context structure now has a member, hdcd_detected, which maybe could be used in some auto-detection code, but nothing like that is currently implemented.

Maybe you are interested in this also: ​http://wiki.hydrogenaud.io/index.php?title=High_Definition_Compatible_Digital

[Christoph Anton Mitterer]

@bp0:

Nice to see :-)
There's still the string "More information about HDCD-encoded audio CDs", would it perhaps make sense to drop the reference to audio CDs there as well?

+1 one to your documentation, especially the note about wav output defaulting to pcm_s16le.

Could one possibly print a warning to the console, that when HDCD filter is enabled *and* HDCD content is actually detected/decoded but the output would be truncated (regardless of the format, so e.g. also in the case of manually selected 8bit FLAC)?
That would be perhaps (maybe even a better?) alternative to my proposal above to automatically default to some higher bitrate in case HDCD was detected.

Last but not least, what do the developers think about automatically trying to detect HDCD and enabling the filter if found?

[bp0]

There may be other filters in the chain, one would have to step through the input and output format of each filter and encoder that comes after the HDCD filter to see if it will be truncated. I'd guess that is possible.

While it certainly would be nice to automatically detect HDCD in the input stream, in ffprobe for example, I'm not sure it would be a good idea to automatically add the filter. All the information that is known about HDCD is from reverse engineering, and there seem to be some yet-unknown extra features of HDCD that are not implemented. IMO, it would better to tell the user that HDCD is detected and let them enable the filter when they desire.

[bp0]

Such a check is added in bea17a3d57053e77a9b3f46291f9d620dd76f7a2

"Scan the chain of AVFilterLinks for any resampling or format conversion/truncation that might cause problems for the filter and issue warnings."

[Christoph Anton Mitterer]

Great :)

Does this also include the information whether HDCD was detected at all? I.e. what you proposed for example for ffprobe?

Oh and you mentioned some yet unknown extra features of HDCD...
You think there are any references where more about that things could be found out?

Over time I collected some docs about HDCD... perhaps they contain more info.
Could upload them here in case you're interested.

I also got a manual to the Model Two HDCD A/D Converter D/A Converter Digital Processor... some HDCD guru once told me it would contain some valuable information. Could send it to you via mail.

Quoting a mail from the same guru:

Attached is the requested manual. Everything is pretty easy to figure out except one thing -- the exact curve for the Peak Extend function. All of the implementations I've seen on the internet appear to simply eyeball the graph in the AES paper and make a close guess.

Not the best way to do it, but better than nothing. Additionally, the maximum expansion possible is +6 dB for PE (one bit), and -4 dB (maximum!) for Low-Level Extension. So we are only talking about turning 16 bit data into 17 bits, or at very most and only on occasion, 17.5 bits. Yet everyone puts the result into 24-bit containers. I don't suppose there is much choice...

The filter encode flag is in the "subcode" as that was part of the original plan. However Ed Meitner (then at Museatex) had already patented a switchable playback filter so Pacific Microsonics couldn't use it.

They must have found that out very late in the process as the "sub-code" for the filter is on every disc, showing which filter was used for the encoding side. But this was never, ever decoded. There was only one playback filter ever used on any HDCD player - period. Everybody is confused by this and speculates about what the "two filters" are. The answer is "they aren't". There is only one filter. It's OK sounding, but not as good as more modern minimum-phase filters that are optimized for superior time-domain performance.

Finally, while the engineering of the HDCD system was excellent, the marketing was total baloney. If the mastering engineers turned off ALL of the features that required decoding, the disc would still light up the HDCD light on the player. This is complete nonsense as there is absolutely nothing to decode. They were simply trying to scare the consumer into believing that they needed to buy an HDCD player. (That is just one example of many, most of them far more deceitful.)

So perhaps that unimplemented feature is one of those you mentioned to be "missing"?

Also I once read that HDCD features could basically be enabled any time in each track (though most implementations only teste the first few seconds), and that features could differ from track to track on a CD (which is of course natural, as HDCD is not CD specific).
So any auto-detection code might already need to scan the whole data?!

Cheers,
Chris.

[bp0]

Chris, thanks for the info. I'm interested in anything you may have, but we should move the general HDCD chat out of this ticket. Come to #ffmpeg or #Hydrogenaudio on freenode, or message me on the Hydrogen Audio forums (​https://hydrogenaud.io/), I'm bp0, or at ​http://wiki.hydrogenaud.io/index.php?title=User_talk:Bp.