SACD Ripping using an Oppo or Pioneer? Yes, it's true!

[Jud]

I will repeat: this ripping capability is available for those BD/universal/SACD players that have the MT8580 or MT8560 chipsets ONLY!

 

Telnet is the only communication vehicle I am aware of that allows one to run this. That requires a LAN connection (I assume wireless is ok but don't know these players' capability).

 

Ah, too bad for me, then - Oppo BDP-83 with MT8520.

[Jud]

Got it working on my Pioneer Elite BFP-80FD, (using the Pioneer 160 package). Couldn't seem to get it working by simply inserting the USB with the correct files and launching sacd.cmd on my PC (sacd.cmd would launch, but immediately crash), but got it working by telnet-ing in (Windows 7 PC/Putty) and following the instructions in ted_b's post #71, but with a slight change in script.

 

Original instructions:

 

 

 

The problem for me was this line: – type ‘cd /mnt/sda1/AutoScriptSACD’ and press Enter

 

 

"sda1" could not be found, but there was a directory "sda", so I changed that line ('cd /mnt/sda/AutoScriptSACD'), then continued (skipping the insmod line, as it didn't seem to work/was not needed with my player), launched sacd.cmd on my PC, and ripping started.

 

Your results may vary, but it's something to try....

 

For someone with your username, that was pretty acute!

[Jud]

Why would you convert DSD to PCM and then back to DSD? At that point, you've converted the file twice so it would make more sense (IMHO) to just leave it in PCM format rather than converting back to DSD.

 

Yes! It is also quite possible the original source for the SACD was PCM so that's yet another format conversion in the chain. Each and every one of these format conversions is NOT LOSSLESS!

 

I guess it's a matter of whether you can hear any diminution of SQ with the AuI offline conversion (knowing the care Yuri takes with his algorithms I'm guessing he tested this issue himself) versus the amount of bother the "ticks"/"clicks" are for you.

[Jud]

Thank you Roberto, very nice explanation.

[Jud]

As I said on a precedent post the differences I'm trying to report here are amplified by an "audiophile vision of the world " and , as you said for USB cable,not enough to matter for most of the people out there , but unfortunately , I do prefer my Oyade USB cable rather than a commercial one, and I do prefer file 3 vs file 1 and file 2.

 

P.S.The fact that File 1 and 2 are indistinguishable is probably the prove that my network is working fine

 

Your assertion that file 3 sounds different than file 1 and file 2 suggests otherwise if we're to believe that it really does sound different. Until you can demonstrate that the file content isn't the same, I'm going to remain extremely skeptical (to say the least). If the file content IS the same, the only way they can sound different is if the playback chain isn't the same when listening to each.

 

May we take this extremely old argument to an extremely new (and more appropriate) thread, please?

[Jud]

I apologise if I made some kind of thread mistake , please understand that I am totally "new" on forum behaviour

 

Not a problem at all. The thread is already quite long, and if it went off topic it would suffer as a resource for people looking for instructions on how to rip, and which players to use.

[Jud]

First, a huge thanks to the folks who developed this and @ted_b who brought it here. My (second) old PS3 was hacking, coughing and sending out flashes of yellow light, so I found an open box BDP-80FD at Best Buy. So nice to have something new with a warranty (and that unlike the PS3, doesn't need a third party fan that sounds like a helicopter taking off to try to get adequate cooling). The USB stick setup for the BDP-160 works beautifully with the BDP-80FD.

 

I'm able to stream the iso to my Mac, which is convenient. However, iso extraction to DSF seems quite a bit slower than on Windows. Is this due to the need to package sacd_extract with Java? Any method of extracting more rapidly on OS X? If not, I can always bounce the iso to Windows or Linux for extraction, though that would be a little less convenient, or just wait for the longer extraction on OS X.

[Jud]

Have you tried Sonore's iso2dsd for the extraction to DSF?

 

I have no Windows or Linux point of comparison for speed, but the .dsf extracts on my Mac mini using iso2dsd go pretty darned fast for me.

 

The build configuration file in the original sacd_extract github is missing the compiler optimization option for both OS X and Linux. As a result sacd_extract Linux binaries available on the web (including those packaged in iso2dsd) are much slower than they should be. I don't have a Mac so I cannot confirm this for OS X, but probably the same is the case for OS X binaries as well.

I tried compiling sacd_extract for Linux with compiler optimization turned on by modifying the build config file. That gave more than 3x speed boost in dsf extraction from the same iso and PC.

 

Thanks, Mike and mindset. Yes, I'm using iso2dsd for the extraction. (Just for clarity, I'm talking about extracting the individual dsf files from the iso, not getting the iso from the disc.)

 

Getting the iso from the disc is nice and fast, but extracting the individual dsf files from the iso works two or three times more slowly than I recall from Windows. Perhaps mindset's thought about the OS X version of the sacd_extract binary not being optimized is correct.

 

I have a couple of questions about optimization. I'm not a developer and don't really know what I'm doing, but have compiled things before in FreeBSD, Linux, and, using XCode, for an OS X native app (Audirvana when it was open source). Thus I can follow "cookbook" instructions, but don't know how to recover from any but the most obvious elementary errors. So this being said, mindset, can you tell me what optimizations you selected? And does anyone know whether XCode will compile sacd_extract on its own, or whether I need something like Homebrew?

 

Thanks all.

[Jud]

Jud... why don't you just use terminal commands instead of the java thing?

That's what I do on my Mac

 

here's the output of ./sacd_extract --help

 

Usage: sacd_extract [options] [outfile]

 

-2, --2ch-tracks : Export two channel tracks (default)

-m, --mch-tracks : Export multi-channel tracks

-e, --output-dsdiff-em : output as Philips DSDIFF (Edit Master) file

-p, --output-dsdiff : output as Philips DSDIFF file

-s, --output-dsf : output as Sony DSF file

-t, --select-track : only output selected track(s) (ex. -t 1,5,13)

-I, --output-iso : output as RAW ISO

-c, --convert-dst : convert DST to DSD

-C, --export-cue : Export a CUE Sheet

-i, --input[=FILE] : set source and determine if "iso" image, device or server (ex. -i 192.168.1.10:2002)

-P, --print : display disc and track information

 

 

I'm ripping directly to DSF (via wi-fi) this way:

 

- prepare a folder somewhere on your HD with sacd_extract binary inside

- type "cd " in a terminal window then drop the above folder in it and hit "enter"

- finally type "./sacd_extract -i 10.0.1.22:2002 -2 -s" (use your ripper's IP and change options as per above: "I" instead of "s" will rip to ISO")

 

never tried but I'm sure you can extract from an ISO to DSF by:

- type "./sacd_extract -i " then drop your ISO file in the terminal window, add " -2 -s" and hit "enter"

That may be a little faster than using the Sonore GUI, but not as fast as I recall on Windows. I want to test with Windows to be sure before going further....

[Jud]

Yep, in fact the difference is even greater than I recalled. About 9-10 times faster for me on Windows (.61-.75MB/s on Mac, 6.5-6.7MB/s on Windows).

[Jud]

.61-.75?

I'm getting between 1.5 to 2.5MB/s ripping direct to DSF via wi-fi

I have an old MacBook Pro (mid-2009, Core 2 Duo 2.53GHz CPU). But OTOH, I have an old Windows/Linux/whatevertheheckIwantoplaywith desktop as well - 2010 Core i7-950, 3.71GHz (spec'd at 3.07 but overclocked ). So that's some of the difference between Windows and Mac, but is it all of it?

[Jud]

its stock 5400rpm HD is the bottleneck

 

Was replaced with an SSD before I bought it refurbished, and has since been upgraded twice. So not that.

 

But in any case, whatever my personal system may have to do with this, it may be worthwhile for someone who has the chops to try to make a binary optimized for OS X. (And then tell those of us who enjoy watching stuff compile how to do it. )

[Jud]

Sometimes the simplest is the best. Hoping OS X has these familiar CLI tools available.

 

Edit: Nope, if I don't want to do a lot of fiddling with environment variables, etc., looks like Homebrew, MacPorts, something like that. Any preference amongst the crowd for either, or another alternative?

 

Sent from my iPhone using Computer Audiophile

[Jud]

Correction: I am NOT posting publicly.

 

Hi mocenigo. I produced a binary myself, following mindset's helpful instructions, but not much if any speed improvement for me. So it could simply be a matter of an older CPU, or I may have effed up the optimized compile somehow. I'm curious to see which it is, so I'd also like to try the optimized binary if you would be so kind.

[Jud]

I was going to do it manually with the "dropped 0s" but you saved me the effort -- which I knew would yield the same results as with ISO2DSD. I'm totally stumped -- everything should work fine -- tray opens, I can ping the Oppo no problem, all software on my PC is there and in place. There HAS to be some small item overlooked in communicating to my PC & from Oppo.

 

Try the Pioneer BDP-160 files/method near the beginning of this thread.

 

 

Sent from my iPhone using Computer Audiophile

[Jud]

I went back to the beginning and I don't see where I'm doing anything different with the Oppo than was suggested with the BDP-160.

 

As I posted previously, the Oppo BDP-105 drawer opens once the USB & folder with files are in it -- no problem there. But whether using the sacd.cmd (containing my Oppo's IP) or Sonore ISO2DSD methods, the doggone thing just won't connect. All I get is that blasted "libsacdread: Can't open 192.168.1.12:2002 for reading" message. Very frustrating, especially when I see others rip with such ease using a 105.

 

Just to be clear, it's not the method discussed right at the beginning, but an alternative one a little bit later in the thread specifically for the BDP-160.

 

The reason I mentioned it is because I was getting the same error as you with the original method, and the alternative method worked.

 

 

Sent from my iPhone using Computer Audiophile

[Jud]

Post #48, I believe.

 

 

Sent from my iPhone using Computer Audiophile

[Jud]

That's the sacd extract for the Pioneer. I thought you had meant a different procedure. It's odd that bobverens gets the same error message that I get, when he has a Oppo 105 hooked to a PC, while I have a 105 hooked to a Mac.

 

Why would the error message from the machine performing a Linux process over a network be different?

 

In any case, the other method is free to try, as are yet other methods from yet other posts.

 

 

Sent from my iPhone using Computer Audiophile

[Jud]

If pl_svn's suggestion does not work, are post #s 821 or 418 at all helpful?

[Jud]

For folks who were still following the story of iso to dsf conversion rates:

 

- I did an optimized compile of sacd_extract on OS X (2009 2.53GHz Core 2 Duo CPU), and got exactly no speed boost with Sonore's iso2dsd. Still a steady .7MB/s.

 

- Using Audiophile Inventory with a *non*-optimized sacd_extract, I got a conversion rate about 3x faster on OS X, about 2.1MB/s.

 

- Using iso2dsd with an optimized (compiled with -O3) sacd_extract on Linux on my desktop (i7-950 CPU overclocked to 3.7MHz), I got a conversion rate of *937*MB/s - a complete iso converted in a couple of seconds.

 

I guess it's something with the difference between the CPUs, eh?

[Jud]

Did you use the same iso for all these tests? Decompressing DST takes considerable processing power, whereas converting an uncompressed iso should be as fast as the storage medium can manage.

Yes, the iso of my hybrid SACD from Jordi Savall and Hesperion XXI, "Altre Follie - 1500-1750."

[Jud]

Does this disc use DST compression?

 

How would I tell?

[Jud]

Doesn't sacd_extract tell you?

 

Very possibly - where in the output would I look? (AuI is chugging along at 2.1MB/s with the iso as I write, and I am looking at the running log. It uses sacd_extract.)

 

 

Edit: I would be happy to provide you a copy of the iso for research purposes if that would be quicker than trying to make me understand what to look for.

[Jud]

I thought it printed this information, but apparently it doesn't. It's been a while since I used it.

 

Now I did a quick test on my i7-940 2.93 GHz Linux system with both the ISO and output in RAM. When not decompressing DST, the whole disc completes in less than a second regardless of compiler options, sacd_extract reporting "infinite" speed. With DST decompression enabled, I get about 2.8 MB/s without optimisation (default build options) and 9.5 MB/s with -O3. I suspect your slow results are doing decompression and the fast one isn't. The speed of the latter is consistent with an SSD.

 

That makes perfect sense. The next question is why the same ISO is treated on Linux as not requiring decompression and on OS X as requiring it, or is that impossible and something else must be going on?

 

 

Sent from my iPhone using Computer Audiophile

[Jud]

Maybe you made a mistake with the settings. Do you have the exact sacd_extract command used in each case?

 

I believe so, but I'll go back and repeat things today or more likely tomorrow to determine what I did differently in one case versus the other.

 

 

Sent from my iPhone using Computer Audiophile