Hoffman gives up on HDCD

[luvdunhill]

That would be Octave.

[mypasswordis]

http://forums.slimdevices.com/showthread.php?t=82970

These people seem to agree that the last 4 bits are padded, and with a 6dB attenuation to account for it.

Sounds to me that using the peak extension is a bad idea but the dynamic range suppression sounds pretty good for lowering the dither floor but at 16 bits that floor is really far down there.

So you think 24 bit hi-rez is excessive?

[aardvark baguette]

you guys are such nerds

[Dreadhead]

So you think 24 bit hi-rez is excessive?

Yes and no. A lot of DACs have noise floors above the -96db that you get from CD. Some don't but the highest I've ever seen was 20 bit or so (like my DAC3) but realistically if I have the volume set so that I can hear the 0dB peaks comfortably (which is like 80dB for me) in my system the noise floor is so far down that I'm not going to hear it over the background (around 30-40db in my house) or my great grandmothers mantle clock.

That said 24bit when you're doing editing or DSP is essential.

you guys are such nerds

And proud of it. If I wasn't such a nerd I wouldn't get paid nearly as much.

Edited April 7, 2011 by Dreadhead

[aardvark baguette]

nerds share, right? Right?

[Dreadhead]

Oh and the 6db attenuation is not for the padding it is for the peak extension so the DAC has enough headroom for the peak. It seems like HDCD gives 1bit MSB before and 3 LSB after with peak extension and 4 LSB without. The extra zeros after are just like adding decimal places and do nothing at all.

[mypasswordis]

Oh and the 6db attenuation is not for the padding it is for the peak extension so the DAC has enough headroom for the peak. It seems like HDCD gives 1bit MSB before and 3 LSB after with peak extension and 4 LSB without. The extra zeros after are just like adding decimal places and do nothing at all.

They do if your DAC is only 16 bits and if it starts reading from the LSB or MSB. Shifting bits to the left = padding with zeroes, and it does mean you need to compensate by attenuation (thus allowing headroom).

[Dusty Chalk]

Edit: Cool thrad http://www.diyhifi.org/forums/viewtopic.php?f=2&t=2056

That is, indeed, fascinating reading. Especially the linked-to thread about the HDCD box (link, and the post two down following that one).

[Dreadhead]

They do if your DAC is only 16 bits and if it starts reading from the LSB or MSB. Shifting bits to the left = padding with zeroes, and it does mean you need to compensate by attenuation (thus allowing headroom).

Sorry but that is what I said. Zero padding by definition is adding to the LSB side so it makes no difference to the signal out of the DAC (if it is 16 bit and correctly ignored the extra LSB bits).

The peak extension on the other hand adds one bit to the MSB side and requires the range be half the gain to keep the not peak extended data in the the correct ratio to the loudest point in the track. (Which is what I said too)

[Dusty Chalk]

"correctly ignoring the extra LSB bits" -- what? You can output a 16-bit signal to a 24-bit DAC, and it should handle it correctly, but if you are putting a 16-bit signal into a 24-bit signal by padding it before sending it to the DAC, aren't you making a 24-bit signal? I don't think it's the DAC that pulls the 16-bit signal out of there, I think that's the transport's job.

[mypasswordis]

Sorry but that is what I said. Zero padding by definition is adding to the LSB side so it makes no difference to the signal out of the DAC (if it is 16 bit and correctly ignored the extra LSB bits).

You can pad either side with zeroes, same like you can read from the MSByte or LSByte (Endianness) first. There is no real convention.

[Dreadhead]

"correctly ignoring the extra LSB bits" -- what? You can output a 16-bit signal to a 24-bit DAC, and it should handle it correctly, but if you are putting a 16-bit signal into a 24-bit signal by padding it before sending it to the DAC, aren't you making a 24-bit signal? I don't think it's the DAC that pulls the 16-bit signal out of there, I think that's the transport's job.

I was talking about putting a 24bit signal into a 16 bit DAC. It should ignore the lowest 8 bits. I'm not saying any do I'm just saying that's what should be done.

Also of interest if you play 24bit material into a 16bit dac you really should add dither or there may be audible effects.

You can pad either side with zeroes, same like you can read from the MSByte or LSByte (Endianness) first. There is no real convention.

Yes there is. Last time I checked when you feed a 16bit signal to a dac using a digital output and then switch your software to 24 bit the newly padded signal doesn't reduce the volume 2^8 times.

Edited April 7, 2011 by Dreadhead

[mypasswordis]

You're clearly not trying to understand me so I'll leave it at that.

[Grahame]

On the software side, it would be interesting to see what Audio Diff Maker had to say about the differences between a pre and post HDCD decoded file

(It has gain compensation, so should cope with the 6dB difference case)

Edited April 7, 2011 by Grahame

[Dusty Chalk]

Hey, guess what I just found.

[Dreadhead]

You're clearly not trying to understand me so I'll leave it at that.

I am trying. Here is what I'm saying (Assuming that I have a 24 bit DAC):

Full range for DAC (0dB):11111111111111111111111

16 bit number(from CD): 1010101010100110 (2^16 steps)

HDCD decode with PE: 0101010101010011101 (2^20 steps but signal now played at 1/2 16 bit playback, or 6db cut)

Zero Padded 16 bit: 10101010101001100000000 (2^24 steps 16 bits of resolution)

Zero Padded HDCD with PE:01010101010100111010000 (2^24 steps 20 bits of resolution, volume 1/2 of 16bit)

MSB padded 16 bit: 00000001010101010100110 (2^24 steps 24 bits of resolution, volume 1/( 2^8 ) of 16bit playback)

I'm not the only one.

http://www.hydrogenaudio.org/forums/lofiversion/index.php/t72436.html

Edited April 7, 2011 by Dreadhead

[grawk]

no 2s in binary files, ever, sorry

[Dreadhead]

no 2s in binary files, ever, sorry

fixed.... sorry about that typo (I had put a 2 in my HDCD data stream)

Edited April 7, 2011 by Dreadhead

[mypasswordis]

Value-wise everything you said makes sense, I'm just saying that depending on what sort of architecture you are dealing with and what you are trying to accomplish, you can pad zeroes on either side (ie zero padding does not imply LSB or MSB side) and can read/write from the LSB or MSB end first, and some things are even bit (as opposed to byte) addressable. Big endian you'd pad zeroes on the left and little endian you'd pad zeroes on the right. Classic example being 0xdeadbeef, little endian in memory by byte would look like

0xef

0xbe

0xad

0xde

[luvdunhill]

This thread is hot, lemme buy you some java y'all 0xcafebabe

[Dreadhead]

Ok well audio was what I was talking about zero padding and having a standard. There are lots of other zero paddings around beyond endian ones (eg ftt).

[deepak]

Would anyone be interested in doing 24/96 vs 16/44 ABX blind tests using foobar2000? I could prepare plenty of samples from various genres and upload in a zip file if enough people expressed interest.

[Dusty Chalk]

Absolutely.

[mypasswordis]

Would anyone be interested in doing 24/96 vs 16/44 ABX blind tests using foobar2000? I could prepare plenty of samples from various genres and upload in a zip file if enough people expressed interest.

I would think that would be a lot easier than ABXing HDCD vs. CD as in principle they are much closer. Not saying I/we'd pass...

[Dreadhead]

I'd be interested too. Are you going to dither it down to 16bit or just cut it off? Apparently if you just cut it off then the difference will likely be a lot more audible (not that I've ever heard it).