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 8886 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

directly saving digital input

i apologize if this has been asked, but i have searched using every possible term i can think of and cannot find an objective answer.

i am looking to save to a WAV file from a digital input via toslink in the native format this it is being received in; bitwise save the data.

i am not looking to really go into the value of doing this but just how to.  i have an oppo bpd 93 that allows HDCD to be decoded but not passed through DAC.  so i can send the decoded HDCD stream out the digital output of the player, and the plan is to capture the digital bits into a new wave file directly.

i have gotten a TOSLINK to USB converter and can see the data coming in and actually save it to a file in Audacity; i set the preferred input to 24bit 44.1k and set the conversion dither to none.  (i would expect not to have to set anything, that there should be an option that can detect what format the incoming content is in in the first place but...) i hit record, play the HDCD, and then export to WAV.  i have done this a few times.

since the data is digital, never (supposedly) having been DAC'd, i'd assume the resulting files from Audactity would match, maybe not in length or null samples in the beginning and end, but there should be something of a match using the Foobar Binary Comparator.  they do not match; from what i can tell it seems to same the entire thing is different.

so the question really is, despite the nonsense i have already tried - how exactly is the simplest way to simply save the incoming data from the digital input directly to a file?  it seems when audacity exports it does some sort of conversion.  am i just using the wrong software?

or maybe i am wrong for thinking multiple passes using the same process should create matching files?  it is digital so the bits should match unless i am really missing something.

Re: directly saving digital input

Reply #1 –
Quote
match using the Foobar Binary Comparator.
Sorry, I'm lost...      You've got the decoded HDCD converted to a 24-bit WAV file, and you're comparing to what?

Re: directly saving digital input

Reply #2 –
i captured the same disc multiple times, so there are multiple copies of the same "data".

i compared those copies, and they do not match.

in other words, doing the same thing twice (or more) but not getting the same results.

Re: directly saving digital input

Reply #3 –
If you want to rip a CD, you use a CD-ROM drive and a secure ripping application (for Windows: EAC/dBpoweramp/CUERipper).

Re: directly saving digital input

Reply #4 –
Quote from: Porcus on
If you want to rip a CD, you use a CD-ROM drive and a secure ripping application (for Windows: EAC/dBpoweramp/CUERipper).
Exactly.  There is nothing to be gained by capturing the "real-time" Oppo digital output.  The Oppo can not pass the HDCD "expanded" bitstream.  You need to play the ripped file through a DAC capable of decoding HDCD.  Even then, there are limitations such as not being able to use any digital volume control ahead of the DAC lest it strip out the HDCD "flags".

Alternatively, there is a plugin for foobar2000 to rip and decode an HDCD to a 24-bit file, but I've never used it.  Pretty sure dBPoweramp can also do this.

Re: directly saving digital input

Reply #6 –
Quote from: Apesbrain on
The Oppo can not pass the HDCD "expanded" bitstream.  You need to play the ripped file through a DAC capable of decoding HDCD."

this is not correct, unless this does not mean what i think it means.
oppodigital.com/KnowledgeBase.aspx?KBID=44&ProdID=BDP-93

i already have a secure rip of the content, i prefer cueripper myself.  i am aware of the multitude of HDCD software decoder options as well. afaik, software decoding is not as comprehensive as passing through a hardware decoder from what i have read here and elsewhere.  if i am wrong, and the software decoder 100% does everything the hardware decoder is doing then please correct me.

Quote from: koawmfot on
i am not looking to really go into the value of doing this but just how to.

I am not doing this cause "you won't be able to hear the difference".  i would like to ABX this myself, and do it where i have an actual legit simple way to compare using the ABX tool in Foobar.  it's really about neurotic completeness for my collection.

let me know what you guys think thanks

Re: directly saving digital input

Reply #7 –
Two possible sources of error:
* You are sure you did align the bitstream up well?
* Once HDCD is switched on, it will be kept alive for ten seconds. That means you can get different results if you play two tracks consecutively, vs if you play the second after a pause.

Re: directly saving digital input

Reply #8 –
Quote from: koawmfot on
this is not correct, unless this does not mean what i think it means.
oppodigital.com/KnowledgeBase.aspx?KBID=44&ProdID=BDP-93
Well, this surprises me.  Not only because it is different from what is printed in the BDP-93 owners manual, but also because I thought Pacific Microsonics license terms prohibited exposing the "decoded" bitstream.

Regardless, you should be able to capture the Oppo playback using Audacity.  Be sure Audacity is set to record at 24/44:
Edit > Preferences > Quality > Sampling

On that same page, disable dither in both "Conversion" options.  That should capture and export the output of your Oppo bit-perfectly so long as the TOSLINK>USB converter is functioning transparently.  The recording gain in Audacity should be set to 100%.  After recording, export to 24-bit WAV or FLAC.

Re: directly saving digital input

Reply #9 –
Quote from: Apesbrain on
Well, this surprises me.  Not only because it is different from what is printed in the BDP-93 owners manual, but also because I thought Pacific Microsonics license terms prohibited exposing the "decoded" bitstream.

Regardless, you should be able to capture the Oppo playback using Audacity.  Be sure Audacity is set to record at 24/44:
Edit > Preferences > Quality > Sampling

On that same page, disable dither in both "Conversion" options.  That should capture and export the output of your Oppo bit-perfectly so long as the TOSLINK>USB converter is functioning transparently.  The recording gain in Audacity should be set to 100%.  After recording, export to 24-bit WAV or FLAC.

awesome thanks.  i have a mail from support before i found that page where i specifically asked him if it would decode without DAC and i was told the BDP 93/95 and 103/105 players do this.

i will confirm this setup and run a couple passes.  i am doing the whole CD in a single shot and will split tracks later (plan is to use an image cue and make the capture image length match the standard CD image and split identically...)  so to get a couple passes will take a few hours.  i'll give it a shot.

Quote from: Porcus on
* Once HDCD is switched on, it will be kept alive for ten seconds. That means you can get different results if you play two tracks consecutively, vs if you play the second after a pause.

hmmm so i did queue up track one paused and wait while i setup audacity.  i did not do this in the next try, so this 100% could be where I screwed up.  going to try the recommendations and see how it works.

i really was looking for confirmation that it is possible to capture the data bit perfectly (or as close as possible) using this process. thanks for the help.

Re: directly saving digital input

Reply #10 –
Quote from: koawmfot on
i am aware of the multitude of HDCD software decoder options as well. afaik, software decoding is not as comprehensive as passing through a hardware decoder from what i have read here and elsewhere.  if i am wrong, and the software decoder 100% does everything the hardware decoder is doing then please correct me.
I think it depends upon which features the HDCD is using. You can rip your CDs normally and then use FB2K to scan the tracks to see which HDCD features are enabled. If the only features are volume adjustment and/or peak extension, the software-based decoding solutions should be the same as what the Oppo does. If the HDCD is using any filters, then you'd need the Oppo to decode it correctly, but this seems to be fairly rare.

HDCD software decoding was reverse engineered from Microsoft's official implementation in Windows Media Player AFAIK, so it should be correct for the features that WMP implemented. If you can get the Oppo capture method working, it would be an interesting experiment to see if the results match what you get with software decoding for a track with peak extension enabled.

Re: directly saving digital input

Reply #11 –
Quote from: Aleron Ives on
If you can get the Oppo capture method working, it would be an interesting experiment to see if the results match what you get with software decoding for a track with peak extension enabled.

this was always part of the plan.

i just did two copies of the same disc.  i followed the configuration suggested, i aligned the starts, and trimmed the end and this is what i get.  i also thought the Binary Comparator would detect offset shifts, could have sworn i did that, but maybe i am wrong, and the tracks are misaligned?

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

Comparing:
"untitled01.wav"
"untitled02.wav"
Compared 154706916 samples.
Differences found: 117542395 values, 0:00.000000 - 58:28.093311, peak: 0.225037 (-12.95 dBTP) at 53:22.082653, 2ch
Channel difference peaks: 0.170013 (-15.39 dBTP) 0.225037 (-12.95 dBTP)
File #1 peaks: 0.988647 (-0.10 dBTP) 0.988647 (-0.10 dBTP)
File #2 peaks: 0.988647 (-0.10 dBTP) 0.988647 (-0.10 dBTP)
Detected offset as 0 samples.



Total duration processed: 58:28.093
Time elapsed: 0:17.409
201.51x realtime

Re: directly saving digital input

Reply #12 –
Quote from: koawmfot on
i followed the configuration suggested, i aligned the starts, and trimmed the end and this is what i get.  i also thought the Binary Comparator would detect offset shifts
You have aligned the starts well, and foo_bitcompare says "Detected offset at 0 samples".
62 percent of the samples compared are common too. A bit hard to read, but the "154706916" samples compared are 154706916 per channel. There are two channels, so in reality it has compared 309413832 samples and found that 191871437 are common and 117542395 differ.

Re: directly saving digital input

Reply #13 –
did a 3rd and 4th pass.

much much better results this time.  not exactly sure what i did differently. 
so after the "recording" finishes, i save it immediately and then on a different PC i am importing the track into audacity and then trimming the front and back and aligning the start time exactly to the start of a normal secure rip, then chopping the end off past the number of samples, then Export again to 24 bit wav and create a "new" file (keep the original recording).

going to try a couple more time, this time doing the trimming right after its recorded so as to minimize the number of import/export in audacity.

edit: i compared the original recordings and bitcompare detected the offsets and it was identical result as the trimmed files, 682 mismatch; so its not the import/export in audacity changing anything.  not bad either really.  comparing in Beyond Compare as hex, its got minimal differences there too.  so i am close, or maybe as close as i am going to get to resproducibility.  my guess is its just not "secure rip" level data coming in from the bit stream maybe?

edit 2: i split the files to the tracks, and got MD5s of tracks.
10/14 tracks match md5, 4/14 are different. 

BC hex compare:

Code: [Select]
928239200 same byte(s)
1690 left orphan byte(s)
1690 right orphan byte(s)
650 difference byte(s)

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

Comparing:
"untitled-3.wav"
"untitled-4.wav"
Compared 154706916 samples.
Differences found: 682 values, 5:28.322086 - 58:27.964649, peak: 0.180267 (-14.88 dBTP) at 52:40.703492, 2ch
Channel difference peaks: 0.169952 (-15.39 dBTP) 0.180267 (-14.88 dBTP)
File #1 peaks: 0.988647 (-0.10 dBTP) 0.988617 (-0.10 dBTP)
File #2 peaks: 0.988647 (-0.10 dBTP) 0.988617 (-0.10 dBTP)
Detected offset as 0 samples.



Total duration processed: 58:28.093
Time elapsed: 0:03.385
1036.32x realtime

what do you guys think?  will i get any more exact or do you think this is it?  or should it be 100% every time?

Re: directly saving digital input

Reply #14 –
Which software option are you using to decode the HDCD? I don't know if they produce identical results.
 

Re: directly saving digital input

Reply #15 –
everything i have done above is the hardware decode for now.

i normally would use CueTools to do the convert., but was going to try a couple others.  not there yet, want to get the hardware decode capture consistent (enough).

thanks

edit - one thing i noticed on the hardware decode, the volume gain/peaks are the same as the secure rip.  its not half like when cuetools does the convert.  also, i have seen that dbpoweramp has a +6cB add to the HDCD conversion to accomodate so i believe its consistent with the software decode for the peak to drop by 6dB?  the hardware decode is not doing that it seems.

once i have this down, i will post a secure rip and a hardware decode rip of a album with peak extension and maybe transient filter and you can software convert with whatever tools you like and compare yourself, i am sure you know 100x as much about this as me.

Re: directly saving digital input

Reply #16 –
Ah, my mistake. I misread your comparisons as hardware capture vs software decode, not two hardware captures. Carry on! ;)

Re: directly saving digital input

Reply #17 –
so turns out i had a thought last night that since this BDP device supports USB media, will it detect a flac rip of the CD so i don't have to use the disc transport?

i got to check this morning and turns out the HDCD light is coming on for a file as well, so no read errors with this method.

doing a couple passes now.

Re: directly saving digital input

Reply #18 –
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 ...)

Re: directly saving digital input

Reply #19 –
following the suggestions from Apesbrain to configure audacity to capture the data bit perfect, and using a file as source instead of disc, i was able to capture the content identically two times over, no differences found.

would this be a bitperfect way to hardware decode HDCD if the source is a verified secure rip, in theory?

anyway the real question was how to use audacity to capture digital signal as-is on a digital input and save direct to file.  thanks for the help.

Re: directly saving digital input

Reply #21 –
this CD does not have any features associated with it as per foobar, so there is probably no value in the one i have been testing with other than getting the process down.

with that said, i had run it through cuetools to decode and it just looks really odd to me in audacity.   this is all three files.
top = HDCD from oppo, middle = normal CD image, bottom = cuetools converted hdcd


i have a disc, sonny boy williamson - portrait of a blues man (1996) that has a minimum gain -4.0, peak extension and intermittent transient filter.  i will convert this and compare.

i am pretty sure i cannot post links to the content here.  let me see if i can find some sample HDCD stuff.

Re: directly saving digital input

Reply #22 –
You can upload samples in the Uploads forum:

https://hydrogenaud.io/index.php?board=35.0

then link to your upload post here. Just clip ~15 seconds of audio in Audacity and upload the WAV or compress to FLAC and upload that.

Re: directly saving digital input

Reply #23 –
i put 15 second clips from the same song, track 1 - little girl, from 3:45-4:00.

https://hydrogenaud.io/index.php?topic=122263

Quote
Sonny Boy Williamson – Portrait Of A Blues Man
Label: Analogue Productions – CAPR 3017
Series: Revival Series – CAPR 3017
Format: CD, Compilation, HDCD
Country: Denmark
Released: 24 Sep 1996
Genre: Blues
Style: Chicago Blues

HDCD flags are as per foobar:  Miminum Gain -4.0dB, Maximum Gain 0.0dB, Peak Extention - Enabled, Transient Filter - Intermittent

ffmpeg output is:
Code: [Select]
[Parsed_hdcd_0 @ 00000261458d9ec0] HDCD detected: yes, peak_extend: enabled permanently, max_gain_adj: -4.0 dB, transient_filter: detected, detectable errors: 0


let me know what you think.  let me know if you want me to pass through any other SW decoder.

Re: directly saving digital input

Reply #24 –
I don't think your CUETools and ffmpeg conversions are correct. The output should be 24 bits, but the WAV files you uploaded are 16 bits. The ffmpeg command should be:

Code: [Select]
ffmpeg -i in.wav -af hdcd -acodec pcm_s24le out.wav

I decoded CD Rip.wav with hdcd.exe and ffmpeg and uploaded them to the same thread:

https://hydrogenaud.io/index.php?topic=122263.msg1009263#msg1009263

The two decoded files are not identical, but they are close. Aside from the different headers, there were 691 differences. The hardware-decoded WAV and hdcd.exe WAV files have completely different samples, because it appears the hardware-decoded WAV has been normalised after decoding; it's much louder than the output of both hdcd.exe and ffmpeg.