In article , Evelyn Carnate
wrote:
On 18/06/2012 16:23, Jim Lesurf wrote:

AIUI MicroSoft took his code and say they put it into their software
players. But they bought the HDCD Patents. I have my doubts they
actually know or care about the details beyond it being another
'feature' they can offer.

It's a while since I looked at it but I thought Windows Media Player
would decode HDCD if you have a 24-bit sound card. WMP11 on my laptop
shows 'HDCD' in the bottom left corner when playing an HDCD.

AIUI both WMP and foobar will 'decode' HDCD. However I'm far for certain
that they do this correctly. I've been looking at the foobar code and it is
rather odd. And it says it is based on the C J Key code, which is also IIUC
what ended up in WMP.

And I thought there were programs available that could intercept data
going to a soundcard and copy it to a file, though whether these work in
24-bit I don't know.

I don't have any problem with recording digital output from a computer.
However:

1) I have no windows machines.

2) I have no idea if foobar or WMP actually do the job correctly.

3) I want to actually detect and examine the embedded codes and their
effects to see how HDCD *actually* works. The Patents, etc, are very vague
about that. I'm far from sure it works exactly as described. And I'd need
that to decide on (2).

4) There is also the issue of being able to develop 'open' decoders and
players and maybe even improve on HDCD once the patents lapse. That won't
be long now, I think. However we need the actual details - not just vague
descriptions and complied code that *might* work - to do that.

TBH so far my impression is that most HDCDs on the market simply use the
'solf limiting' to get LOUDNESS. Albeit in a way that a minority can
'correct'. This aspect is actually easy to correct *if* you can identify
affected material. So the CJK and foobar (and WMP) may get that right, but
I'm less sure of the other aspects.

I suspect there is a divide here. 'Classical Music' HDCDs may *not* use the
soft limiting much. But pop/rock probably use that and none of the other
claimed 'features' of HDCD. And for pop/rock the soft limiting decoding
will have a fairly obviously audible effect making HDCDs sound 'better'
when decoded. So promoting a myth that HDCD is better than CD when in
reality a CD simply recorded carefully at a lower level might sound as
good.

Slainte,

Jim

--
Please use the address on the audiomisc page if you wish to email me.
Electronics http://www.st-and.ac.uk/~www_pa/Scot...o/electron.htm
Armstrong Audio http://www.audiomisc.co.uk/Armstrong/armstrong.html
Audio Misc http://www.audiomisc.co.uk/index.html

Update for anyone interested...

On 30 Jun, wrote:
In article , Evelyn Carnate
wrote:
On 18/06/2012 16:23, Jim Lesurf wrote:

It's a while since I looked at it but I thought Windows Media Player
would decode HDCD if you have a 24-bit sound card. WMP11 on my laptop
shows 'HDCD' in the bottom left corner when playing an HDCD.

AIUI both WMP and foobar will 'decode' HDCD. However I'm far for certain
that they do this correctly. I've been looking at the foobar code and it
is rather odd. And it says it is based on the C J Key code, which is
also IIUC what ended up in WMP.

The more I look at the foobar 'source code' the more it looks like it isn't
all real useable code but a sort of 'pseudo-C' outlining the general
behaviour. For those who know 'C' the following comments are examples of
what is odd...

The .c file has no 'main()' nor is one referenced or somewhere else like in
the .h file. It is just some blocks of data and some proceedures.

Many variables have no starting value given before being used.

Many variables have no defined type.

In various places one variable is set equal to another with no casting.

It also does things like use 'samples' as an array name and 'sample' for
individual values, which makes reading a PITA as the container and the
contained have almost the same name. Oh, and in neither case is the type
clear. Nor is it clear if there are two sets (left and right) or one, with
a specific arrangement for left and right in one block.

And the control code detection process in the program seems to have no
relationship to what is described in the Patent, etc.

So - as with the Patent and AES paper - it seems to be a sort of 'hunt the
clues' set of writings rather than normal computer code. I'm wondering if
the 'C' version is just a set of notes. But I'm not sure if the C++ is any
better!

This in turn makes me wonder if WMP and Foobar actually do correctly and
fully 'decode' HDCD.

However I've started writing up an explanation of how HDCD *says* it works
and how it *says* it does this, along with some practical results and
comparisons to probe the claims. The lack of a reliable decoder doesn't
help. But I realised that it is useful that some discs are hybrids with an
SACD layer to compare with the HDCD-replayed-as-CD. :-) And for rock/pop
HDCDs it is of interest to simply expand out the peak soft limiting and
compare that with the as-a-CD results.

Anyone know what makers currently sell HDCD players? I know of the Oppo
(and it CA version) but that is a play-all BD player. Is anyone like Denon
or Marantz or other mid-market audio maker producing HDCD players? I'm
wondering what people are expected to play these discs on. (Apart from Linn
who, I imagine, assume you have to buy a Linn. Any other player is clearly
no good ahem as the results may show. ;- )

Slainte,

Jim

--
Please use the address on the audiomisc page if you wish to email me.
Electronics http://www.st-and.ac.uk/~www_pa/Scot...o/electron.htm
Armstrong Audio http://www.audiomisc.co.uk/Armstrong/armstrong.html
Audio Misc http://www.audiomisc.co.uk/index.html

On 01/07/12 10:07, Jim Lesurf wrote:

However I've started writing up an explanation of how HDCD *says* it works
and how it *says* it does this, along with some practical results and
comparisons to probe the claims. The lack of a reliable decoder doesn't
help. But I realised that it is useful that some discs are hybrids with an
SACD layer to compare with the HDCD-replayed-as-CD. :-) And for rock/pop
HDCDs it is of interest to simply expand out the peak soft limiting and
compare that with the as-a-CD results.


Hi Jim,

I know you said that you have a coder looking at the source, but if you
need another set of eye's, throw the source at me and I will see if I
can work out what the code is doing without looking at any patients,
then you can compare that with what you think it should be doing.

Having been writing C for over thirty years (where did they go) I have
seen all you describe and more, and some of the things you describe may
be perfectly valid C

"The .c file has no 'main()' nor is one referenced"

It may be code that produces a library that is designed to be loaded at
run time, so the entry point will be something other than main().

"Many variables have no starting value given before being used."

Common in C, if static they will start as 0 by the loader, if automatic
then whatever is on the stack at that time. perfectly valid, and any C
coder would initialize before use if not at declaration.

"Many variables have no defined type."

Well, all variables will have a type, but in common with its origins, C
assumes the coder is competent, and will do as he/she says. So for
example void * is a perfectly valid type, its a pointer to something

"In various places one variable is set equal to another with no casting."

Again, perfectly valid, C has defined rules for those conversions, and
assumes the coder knows what will happen.

--
Nick

In article om, Nick
Gorham wrote:

Hi Jim,

I know you said that you have a coder looking at the source, but if you
need another set of eye's, throw the source at me and I will see if I
can work out what the code is doing without looking at any patients,
then you can compare that with what you think it should be doing.

Hi Nick,

I'd *welcome* you having a look! I'm quite happy to accept that the problem
may be my lack of real understanding of both 'C' and 'C++'. I really would
love to find out how the program can be made to work. This would mean I (or
we.. or you! 8-] ) could produce both an analysis program and an example
that will 'decode' HDCD for test purposes, etc, so people can judge for
themselves on what HDCD does.

The code I've been looking at is available via a zip linked to

http://kode54.foobar2000.org/

where it is in 'foo_hdcd_source'.

The C++ is too much for me, and if I just look at the .c and .h for what
seems to me to be the 'C' alternative (hdcd_decode) I am baffled in the
ways I described! So I can make sense of some parts - like the peak lookup
table for correcting the peak limiting - but can't work out how to detect
the control codes (said to be) in the LSB stream.

Can you please contact me by email? e.g. replace the 'noise' in the name I
post under with 'web' as suggested by my website. I can then explain more
about what the HDCD is claimed to do, and how it is claimed to do it. If
you wish I can also let you have a draft of what I've written up so far.
inc some test results on some HDCDs.

Slainte,

Jim

--
Please use the address on the audiomisc page if you wish to email me.
Electronics http://www.st-and.ac.uk/~www_pa/Scot...o/electron.htm
Armstrong Audio http://www.audiomisc.co.uk/Armstrong/armstrong.html
Audio Misc http://www.audiomisc.co.uk/index.html

On Mon, 02 Jul 2012 13:30:33 +0100, Jim Lesurf wrote:

I'd *welcome* you having a look! I'm quite happy to accept that the
problem may be my lack of real understanding of both 'C' and 'C++'. I
really would love to find out how the program can be made to work. This
would mean I (or we.. or you! 8-] ) could produce both an analysis
program and an example that will 'decode' HDCD for test purposes, etc,
so people can judge for themselves on what HDCD does.

The code I've been looking at is available via a zip linked to

http://kode54.foobar2000.org/

where it is in 'foo_hdcd_source'.

The C++ is too much for me, and if I just look at the .c and .h for what
seems to me to be the 'C' alternative (hdcd_decode) I am baffled in the
ways I described! So I can make sense of some parts - like the peak
lookup table for correcting the peak limiting - but can't work out how
to detect the control codes (said to be) in the LSB stream.

Can you please contact me by email? e.g. replace the 'noise' in the name
I post under with 'web' as suggested by my website. I can then explain
more about what the HDCD is claimed to do, and how it is claimed to do
it. If you wish I can also let you have a draft of what I've written up
so far. inc some test results on some HDCDs.

Hi Jim,

I have also taken the liberty of looking at the source code.

At the risk of teaching my grandmother how to suck eggs...

The HDCD decoder in hdcd_decode.c has two entry points (called from
dsp_hdcd.cpp):

hdcd_reset: This is passed a decoding context, which it uses to keep
track of where it is in the decoding process. There is one context per
channel and this function is called once per channel for initialisation.
This function is also passed the sample rate.

hdcd_process: This is called every time there is a chunk of data to
decode. It seems as if the sample data contains values for each channel
in turn (e.g. L,R,L,R... for stereo). This function is passed the
context, the un-decoded samples, the number of samples and the number of
channels ("stride"). Decoding is performed in place, with result
overwriting the input buffer. This function is also called once per
channel for each chunk of data. (The address of the sample data is offset
on each call so that it points to the first entry for the channel being
decoded.)

Cheers,


Chris.

In article , Chris
Isbell
wrote:
On Mon, 02 Jul 2012 13:30:33 +0100, Jim Lesurf wrote:

I'd *welcome* you having a look!
[snip]

I have also taken the liberty of looking at the source code.

At the risk of teaching my grandmother how to suck eggs...

The HDCD decoder in hdcd_decode.c has two entry points (called from
dsp_hdcd.cpp):

hdcd_reset: This is passed a decoding context, which it uses to keep
track of where it is in the decoding process. There is one context per
channel and this function is called once per channel for initialisation.

So there are *two* independent 'hdcd_state-t' structures, one for 'left'
and the other for 'right'?

This function is also passed the sample rate.

This puzzled me because my understanding is that HDCD encoded material will
- at input - only ever be 44,100 samples/sec and 16 bit.

That said, another puzzle is that HDCD 'DACs' are supposed to upsample the
output to 88,200 to let them apply the various filters that the specs say
it can select on replay. Again, I could not see any sign of this in the
code and have been suspecting that C.J.Key, etc never were able to find out
what these filters were. Another specific detail omitted from the documents
I've seen!

hdcd_process: This is called every time there is a chunk of data to
decode. It seems as if the sample data contains values for each channel
in turn (e.g. L,R,L,R... for stereo).

This was what puzzled me given the above. So the program uses two state
structures but interleaves the L,R samples when finding the control
sequences?

One of the confusions I had from the (vague) Patent, etc, is that in places
it says the data is given (by implication) independently for L and R so
they can be controlled seperately, but then it seemed odd if they need to
have any gain or peak settings kept in sych to avoid a mess when played as
a 'normal' CD. So I've been suspecting that the data stream in the LSBs in
interleaved whilst the Patent seems to say otherwise.

And is the chunk size fixed somewhere, or can I use any size that suits me?
This was another value that I could not see being set at the start of the
process.

This function is passed the
context, the un-decoded samples, the number of samples and the number of
channels ("stride").

Ah, so 'stride' is always set = 2 for stereo? Again, what is curious about
that is that is supposed to be a stereo only system as it is meant to play
on normal CD players.


Decoding is performed in place, with result
overwriting the input buffer. This function is also called once per
channel for each chunk of data. (The address of the sample data is
offset on each call so that it points to the first entry for the
channel being decoded.)

I'll look at the dsp_hdcd.cpp again, although I do struggle with C++.
Again, what isn't clear to me is how the values in 'samples' are held. Is
this a 32-bit per value signed array? Again, from an audio CD - which is
the only defined way to convey HDCD, all values will be 16bit - so given
the inplace changes to yield 20bit results I assume this all have to be
promoted to 32bit?

FWIW I normally use 32 bit as standard and has suspected that as the output
will be 24bit/sample. However I was also uncertain about the 'window' value
in the state structure being 'uint64_t' which I take to be 64 bit unsigned
(?). Yet elsewhere it seems to be being used with 32bit ones...

Is each decode after the first 'find' of a recognised pattern done after a
readahead of a length set by the updated value of readahead? Again this
wasn't something clear to me, or how the system synchs up.

Another puzzle. The documentation says the control patterns are spread
(scrambled) by a simple MLS. But to my ignorant eye the process used in the
decoding proceedure doesn't look at all like that. It just seems to pick up
a specific set of values. I've been wondering if CJK just found what
patterns correlated with specific reactions of features so just senses them
as a 'lookup' in their scrambled state. (?)

Another aspect of this is that I expect to work using LPCM wave files for
the input source and then write out to another one. (input here being
16bit, and output being 24bit.) The code in the .c file seems to take
dealing with that for granted, which is OK, but made me wonder if I was
missing something!

As with Nick, you would be welcome to email me about this if you want more
info on what the system is claimed to do, and how it is said to do it.

Cheers,

Jim

--
Please use the address on the audiomisc page if you wish to email me.
Electronics http://www.st-and.ac.uk/~www_pa/Scot...o/electron.htm
Armstrong Audio http://www.audiomisc.co.uk/Armstrong/armstrong.html
Audio Misc http://www.audiomisc.co.uk/index.html

Just posting to say a big "Thank you!" to Nick for his help making sense of
the foobar code and providing me with a way to run and use it for my test
purposes. I don't think I would ever have managed this without his kind
help.

All being well, I can now do a better investigation of what some HDCDs
really do in practice, as distinct from the 'generous' claims for it in the
Patent, etc... I'll say more once I have some results.

Slainte,

Jim

--
Please use the address on the audiomisc page if you wish to email me.
Electronics http://www.st-and.ac.uk/~www_pa/Scot...o/electron.htm
Armstrong Audio http://www.audiomisc.co.uk/Armstrong/armstrong.html
Audio Misc http://www.audiomisc.co.uk/index.html

Pleased to say I've been making some progress with this using the foobar
code and the 'wrapper' for using it that Nick kindly wrote. I should have a
full report up sometime in the next few days. (Still trying to make sense
of one or two discs.) But people might find the following 'taster' of
result of interest.

http://jcgl.orpheusweb.co.uk/temp/Fig6_Mephisto.png

Shows the results for one example. Track 1 from a Reference Recordings
HDCD. This seems to be the 'best' example I've found so far. Perhaps not
surprising given that it was recorded by 'Prof Johnson' who co-invented
HDCD!

The top graph shows how the peak power varies when the track is played by a
CD player. (Peak in each successive 100 millisecond section.)

The middle graph shows the *change* in level caused by running it through
the foobar process. (Which seems to deal with peak compression and low
level gain twiddling. But *not* with any playing around with filtering.)

The middle graph would be a flat line at -6dBFS if the track were plain
Audio CD material. Where it goes above -6dBFS the effect is due to HDCD
correcting peak compression. So happens in the 'loud parts'. When it drops
below -6dBFS it is due to gain tampering for quiet sections of music.

The lowest graphs compares the foobar process with simply assuming
thoughout that the material needs peak correction. If the material is HDCD
that *only* uses peak compression this would be a flat line at 0 dBFS. Here
is shows that the 'blind' peak expanding is missing dealing with the low
level alterations that the track also contains.

I've actually had a range of results. This is the one with the largest
'expansion' in dyanamics. Looks to be about 8dB from the biggest peak to
the lowest down-gain. So rather less than 2 bits-worth. Nothing like the 4
bits worth (24dB) claimed for HDCD. But I'll keep looking at other
material.

Slainte,

Jim

--
Please use the address on the audiomisc page if you wish to email me.
Electronics http://www.st-and.ac.uk/~www_pa/Scot...o/electron.htm
Armstrong Audio http://www.audiomisc.co.uk/Armstrong/armstrong.html
Audio Misc http://www.audiomisc.co.uk/index.html

I just remembered that my £20 Tesco (Technika) DVD player claims to play
HDCDs.
The setup menu has 3 settings for HDCD: OFF, X1 and X2.
There was of course no documentation to explain what these settings do.
I guess that X1 and X2 control the headroom extension feature.
If I could find which of my discs have headroom extension enabled ...

--
Eiron.

In article , Eiron
wrote:
I just remembered that my £20 Tesco (Technika) DVD player claims to play
HDCDs. The setup menu has 3 settings for HDCD: OFF, X1 and X2. There
was of course no documentation to explain what these settings do. I
guess that X1 and X2 control the headroom extension feature. If I could
find which of my discs have headroom extension enabled ...

FWIW I'm hoping/planning to add a 'diagnostics report' ability to the code
based on foobar/Nick that I'm using. That could then be used to examine
ripped wav files and tell the user if it finds the codes for peak expansion
or low-level gain changes. Perhaps also give some stats on how much this
'expands' the resulting dynamic range of what it finds.

This could be useful for various reasons. Even in the limited number of
discs I have, I've found one with no external mention of being HDCD, but it
uses both features quite a lot. And another that has the HDCD logo on the
back, but no sign of any control codes! This seems to be another area where
parts of the 'music biz' are rather, erm, disfunctional. You can't rely on
what you read on the outside of the box.

Afraid that the (claimed) 'filter adaptions' are out of scope, though. So
far as I can tell, the C J Key and Foobar code doesn't deal with those. In
fact, I doubt that even the MS programs do.

Slainte,

Jim

--
Please use the address on the audiomisc page if you wish to email me.
Electronics http://www.st-and.ac.uk/~www_pa/Scot...o/electron.htm
Armstrong Audio http://www.audiomisc.co.uk/Armstrong/armstrong.html
Audio Misc http://www.audiomisc.co.uk/index.html