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: directly saving digital input (Read 8675 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Re: directly saving digital input

Reply #25
ugh i was working with the whole files, which are decoded properly.   I screwed up exporting the 15sec clips with Audacity and didn't changed back from 16 bit signed.  the sources were 24 bit.  my mistake.  either way, mine are different as the full songs, but i used cuetools and ffpmeg.

i uploaded proper 15 sec clips for the CUEtools and FFMpeg decodes i did.

im curious what you think of the cuetools conversion; i uploaded it properly this time, as well as the ffmpeg that was clipped from the larger file conversion.

sorry for the confusion, way too many things at once.  thanks.

Re: directly saving digital input

Reply #26
The hdcd.exe and CUETools decodes are identical. Aside from the headers, our two ffmpeg decodes are also identical. There are still 691 differences between the hdcd.exe/CUETools and the ffmpeg decodes. I suppose they could be some kind of metadata, but I'm not very familiar with the structure of WAV files.

Re: directly saving digital input

Reply #27
The "HW Decode" and the "CD Rip" are bit-identical except that the "HW Decode" is padded to 24 bit. So the hardware DAC has done nothing to it.

There are still 691 differences between the hdcd.exe/CUETools and the ffmpeg decodes. I suppose they could be some kind of metadata, but I'm not very familiar with the structure of WAV files.
When foo_bitcompare says 691 different samples, it is the audio and has nothing to do with metadata. But see the peaks:
Code: [Select]
Differences found: 691 values, 0:00.520522 - 0:14.864467, peak: 0.000002 (-114.95 dBTP) at 0:00.520658, 1ch
Channel difference peaks: 0.000002 (-114.95 dBTP) 0.000002 (-114.95 dBTP)
So, they differ in the 20th bit. Makes me believe it is round-off. And that ffmpeg puts more noise in the 20th bit, by the compressed sizes.

Which are quite "interesting" when you compare encoders:
Code: [Select]
1 870 208 SW Decode - CUETools.flac
1 887 338 SW Decode - CUETools.tak
2 001 618 SW Decode - ffmpeg.flac
2 064 470 SW Decode - CUETools.wv
2 129 060 SW Decode - CUETools.ofr
2 173 188 SW Decode - ffmpeg.tak
2 549 680 SW Decode - ffmpeg.wv
2 790 492 SW Decode - ffmpeg.ofr
2 925 898 SW Decode - ffmpeg.m4a
2 925 898 SW Decode - CUETools.m4a
flac -8pe smaller than TAK -p4m smaller than WavPack -hhx6 smaller than OptimFROG --preset max (smaller than OptimFROG --preset 10, so it isn't a weirdo that fools max), anyone?

Re: directly saving digital input

Reply #28
The "HW Decode" and the "CD Rip" are bit-identical except that the "HW Decode" is padded to 24 bit. So the hardware DAC has done nothing to it.
His CD player doesn't actually support HDCD decoding, then?

When foo_bitcompare says 691 different samples, it is the audio and has nothing to do with metadata.
I compared with a hex editor, not foobar2000, so I didn't have access to any information about the meaning of the differences. Thanks for the clarification.

Re: directly saving digital input

Reply #29
The "HW Decode" and the "CD Rip" are bit-identical except that the "HW Decode" is padded to 24 bit. So the hardware DAC has done nothing to it.
His CD player doesn't actually support HDCD decoding, then?

That is a possibility. Or potentially that the peak extend flags are false positives.

But, had it been me, I would have looked for user errors first, clumsy as I am. @koawmfot , the procedure seems to be here: https://www.oppodigital.com/KnowledgeBase.aspx?KBID=44&ProdID=BDP-93 Sure you have enabled it?

Re: directly saving digital input

Reply #30
It is kind of hard to have a false positive with HDCD version b, since it does a complex LFSR dance to control packet integrity.

Re: directly saving digital input

Reply #31
The "HW Decode" and the "CD Rip" are bit-identical except that the "HW Decode" is padded to 24 bit. So the hardware DAC has done nothing to it.

are you saying its not really decoding anything?  do you think it would be worth while to try and capture it as 16bit in audacity and see if it is bit aligned to the original source?
EDIT: what tool are you using to figure that out?

But, had it been me, I would have looked for user errors first, clumsy as I am. @koawmfot , the procedure seems to be here: https://www.oppodigital.com/KnowledgeBase.aspx?KBID=44&ProdID=BDP-93 Sure you have enabled it?

its enabled.  i referenced that KB earlier in the thread.  i also have a mail from support confirm that it should decode HDCD without doing DAC.
HDCD ON

the HDCD light is coming on too.  I am going to try changing the Coax/Digital output to LPCM (from bitstream), see if is different.  nothing to lose.  (EDIT: This did not change anything, and i believe it is specific to DSD output.  same MD5 on the new capture.)

i have another disc with peak extension, Cat Power - Moon Pix (1998, Label: Matador, Catalog#: OLE 286-2); no mention its HDCD on the case too.  this has no gain and no transient filter, only peak extension.  i can try that if you're interested.  if you have a track or anything you want to pass along i can try to convert too, PM me?

as far as user error, that's entirely possible, but this is very basic.  optical out on the oppo, to the optical->USB on the PC, and Audacity set to Quality 44.1/24bit, none for dither.  hit record, play the track, align the start and set total number samples and export.

(there is one odd thing, and it is when it is playing the CD, it does say "Track Type: HDCD, Channel Type: Stereo 44.1k 16b".  i would have thought it would say 24b, but then it could jsut be the pre-decode data?)

Re: directly saving digital input

Reply #32
qq - is there a tool or app that can show me what the bitstream info is as it is coming in to the PC? 

Re: directly saving digital input

Reply #33
The "HW Decode" and the "CD Rip" are bit-identical except that the "HW Decode" is padded to 24 bit. So the hardware DAC has done nothing to it.

are you saying its not really decoding anything?  do you think it would be worth while to try and capture it as 16bit in audacity and see if it is bit aligned to the original source?
EDIT: what tool are you using to figure that out?

i grabbed a 16bit import of the bitstream and it does not match the source file at all.

Re: directly saving digital input

Reply #34
Replaygain values in attached pic. You can see the software decodes have done the thing where they halve the levels to make room for the peak extension. HW decode has not. So yeah looks like the HW decode isn't doing it's job.

Re: directly saving digital input

Reply #35
I believe i know why the HW Decode did not work as expected.

Yes, HDCD is flagged in-signal, so unless the device is deliberately turning off HDCD detection for that input, you should get it.

Of course you have to pass a 16-bit file that is not already HDCD decoded. (If not ... it seems to me that HDCD packets can survive HDCD decoding, so ...)

From what i can tell the player is NOT decoding HDCD for file-based input.  so it must be deliberately turning off HDCD detection for that input.

I had said the HDCD light was on when playing the USB files.... turns out if there is a CD in the player that is HDCD, it will ALWAYS show HDCD light, no matter what content is playing.

so as @porcus said, user error.  anyway, i need to now burn some clean discs to try to copy in (most of my collection is digital only rips at this point, media has been long gone.)

I will get a new HW Decoded sample up shortly.

thanks

Re: directly saving digital input

Reply #36
Replaygain values in attached pic. You can see the software decodes have done the thing where they halve the levels to make room for the peak extension.
Hmmm... Now I'm wondering how this relates to HDCDs with the minimum gain -4.0 dB flag. Most of my HDCDs have both peak extension and -4.0 dB min, but one disc has only peak extension. Would you happen to know how this influences the decoding process, if peak extension always requires cutting the volume in half?

Re: directly saving digital input

Reply #37
I'm not the best person to ask but my understanding is the "gain" cuts the volume of the quiet parts.

As for peak extension, if you didn't lower the volume first you would end up with clipping as the peaks have nowhere to extend to.

Re: directly saving digital input

Reply #38
Yes, my question is since you already have to cut the volume by half for peak extension to work, what's the point of the -4.0 dB minimum flag?

Re: directly saving digital input

Reply #39
That is at the quiet end. Peak extension is at the loud end.
The point? To get more out of the bits overall.
(Disregarding the alternative answer: "pointless, you don't need more than 96 dB properly dithered". Oh, and: part of those "20 dB" promised - which weren't 20, it were >19 hence rounded up to 20 - was the dithering. So it was for the full HDCD process, including that part which also is performed when decimating 24 bits to 16 without HDCD - it is not apples to apples, it is apples to non-dithered oranges.)

Re: directly saving digital input

Reply #40
Yes, my question is since you already have to cut the volume by half for peak extension to work, what's the point of the -4.0 dB minimum flag?
The gain isn't applied unconditionally to the whole signal, it begins to get applied only when the signal drops below a certain volume threshold, and it scales progressively as the volume gets lower, until the full 4dB is applied.


 

Re: directly saving digital input

Reply #42
I have successfully and reproducibly captured the HW decoded output.

new HW decode file is here:  https://hydrogenaud.io/index.php?topic=122263.msg1009436#msg1009436

Two passes with the same clean burned CD (to minimize read errors) i was able to get (mostly) identical copies of the disc in decoded HDCD.  the differences are in the end of the data not in any of the audio, so all tracks matched MD5 from both extractions, except the last track which has issues in 1008 samples in the dead space after the last track.

Code: [Select]
Differences found in compared tracks.
Zero offset detected.

Comparing:
"\\infinity\continuum\music\proper\williamson, sonny boy\{1996} portrait of a blues man\test\sbw-clean-fulldisc-p01.wav"
"\\infinity\continuum\music\proper\williamson, sonny boy\{1996} portrait of a blues man\test\sbw-clean-fulldisc-p02.wav"
Compared 103338060 samples.
Differences found: 1008 values, 39:03.148707 - 39:03.179138, peak: 0.000031 (-90.31 dBTP) at 39:03.148707, 2ch
Channel difference peaks: 0.000031 (-90.31 dBTP) 0.000031 (-90.31 dBTP)
File #1 peaks: 0.895081 (-0.96 dBTP) 0.857697 (-1.33 dBTP)
File #2 peaks: 0.895081 (-0.96 dBTP) 0.857697 (-1.33 dBTP)
Detected offset as 0 samples.



Total duration processed: 39:03.267
Time elapsed: 0:12.731
184.07x realtime

I'd consider this successful extraction of the content.

Can anyone tell what is happening here that maybe SW decode does not do or where there may be gaps?  love to hear what you guys think.

I can also add more samples, of other HDCDs with different feature profiles?  let me know, and if you want to pass something along i can test too.  just PM.  Sonny Boy is the only disc i have with gain at all, and the only one with all the features.

One big observation I had on SW v HW decode... not with this particular disc, but on one with an HDCD flag, but NO HDCD features detected - it will NOT half the levels to make room for peak extension.  My guess is any disc without peak extension enabled will not have volume levels adjusted.  i will create a few sample rips and post.

thanks//