This screenshot is the menu from brp

OK, so just enter that assigned IP of 192.168.0.16 into the ISO2DSD application's Server input screen.

But be sure to also do the previously mentioned steps 1-4 while you have the HDMI cable connected.

By the way, you can leave the S390 connected in the other room with the TV if you like, it does not need to be near the computer for any reason, just connected to the same LAN.

While that may mean some walking back and forth, it also allows you to access the on-screen displays. The S390 will then transmit the .dsf Files over the LAN to your Mac.
 
I tested SACDExtract now on a Win 10 - machine - well, to be honest, not completely so far. I only tried to extract the Multichannel Tracks from the ISO's I ripped with ISO2DSD...
...it didn't work - no matter what I tried.
I tested virtuallly any possible combination of settings and tested 4 different ISO's.
It seems as if the GUI starts the .exe with different command line -arguments, depending on what you chose before, but all I get afterwards is a [Done] - immediately, in less than one second. No output on the chosen folder.

I ran it on exactly the same machine I successfully ripped the SACD's on...

...will try to rip one of the SACD's freshly with SACDExtract - but not today - it's 1:30 am in Germany right now...

...Good Night! :-)
 
I tested SACDExtract now on a Win 10 - machine - well, to be honest, not completely so far. I only tried to extract the Multichannel Tracks from the ISO's I ripped with ISO2DSD...
...it didn't work - no matter what I tried.
I tested virtuallly any possible combination of settings and tested 4 different ISO's.
It seems as if the GUI starts the .exe with different command line -arguments, depending on what you chose before, but all I get afterwards is a [Done] - immediately, in less than one second. No output on the chosen folder.

I ran it on exactly the same machine I successfully ripped the SACD's on...

...will try to rip one of the SACD's freshly with SACDExtract - but not today - it's 1:30 am in Germany right now...

...Good Night! :-)

Thank you very much for testing it, I don't know why that happened as the problem you are describing was one of the early reported bugs that was supposed to have been squashed in the beta testing.

My own tests of the new compile for Mac were quite successful, but I haven't tried the newest Windows version yet, only the beta to this point.

In my tests I ran Concurrent mode to both create an ISO and extract .dsf from it simultaneously, and that did work, the test was in Post #191.

Another member here is going to test the Windows version, lets see how he does and then maybe send some feedback to the developer that can help solve any remaining issues.

Another possibly interesting test would be to take the sacd_extract 3.9 .exe piece in that new package and make a copy of it to place in your ISO2DSD folder (while temporarily removing the sacd_extract .exe piece that is currently there). In my tests, after making a temporary folder to safely house the original sacd_extract found in the Sonore package and replacing it with a copy of 3.9, the ISO2DSD program also works faster, though you don't then get all of the added functionality of the newer SACDExtractGUI. That test was in Post #174.

So you could try that if you like and that would at least point to whether or not the issue is with the new GUI, or the Windows version of sacd_extract 3.9 itself. I would tend to doubt the problem is with the GUI as it's really just a Java based front end to sacd_extract, however it might be interesting to try the above anyway.
 
Thanks for the possible workaround - I will test that soon...
...however, as I already reported, I experienced almost the same with Iso2DSD before - but now the other way round!
After about 1 hour of frustrating testing I simply switched back from my old notebook that works perfectly with Iso2DSD to the about 11-12 years younger All-In-One PC - and everything works great there with SACDExtractGUI, no problems at all, extrackting takes place at about 3.7 MB/sec.
Both machines work on the actual version of Win 10, however, the hardware is extremely different 11-12 years later, of course.
I have absolutely no idea what might cause these problems, but at the moment I'm happy to be able to extract the SACD's to ISO's or stereo tracks on the old system and extract the multichannel tracks afterwards on the new system!
So far I tried to ectract 4 CD's, 3 worked fine, one of them seems to have no multichannel tracks (a japanese pressing of 'Dire Straits - Alchemy').
I will now work through my small collection and afterwards I will try to find out the problem - but at the moment I don't even know where to start - both systems are so completely different - except for the OS installed...
 
Lesson learned:
Never throw away old hardware or sell it on eBay for a few bucks...
...neither your old notebook, nor your old Sony Blu-Ray player!

Very interesting, so now at least both systems actually work!

It's great when old stuff like that becomes new again, all new utility from old almost forgotten units is fantastic!

Also good that your newer potentially much faster computer hardware is finally cooperating!
 
I am still a bit confused on the SACD ripping process. Should I be using SACDExtractGUI.jar or ISO2DSD software to do the ripping?
The GUI is the latest version of the Java interface. It needs SACDextract that you compiled to operate. You point the GUI to the compiled SACDextract and run. ISO2DSD was an earlier front end with fewer bells and whistles like the ping & test buttons and the ability to send files where you want them.
 
I am still a bit confused on the SACD ripping process. Should I be using SACDExtractGUI.jar or ISO2DSD software to do the ripping?

What do you wish to do, just extract stereo .dsf tracks, or do you wish to create full archival back-up ISOs of the entire SACD disc (or maybe both)?

For just pulling the stereo as .dsf, the original program detailed here called ISO2DSD is just fine. For additional functions such as Concurrent mode for both ISO and .dsf creation simultaneously, and the ability to specify separate output directories etc, as well as the above post's mention of the Ping and Test buttons, you would substitute the newer SACDExtractGUI in place of ISO2DSD.

In either of the above cases, you use the same AutoScript on the USB thumb drive inserted into the Blu-ray player, that part doesn't change at all.

The front-end GUI choices above (either ISO2DSD or SACDExtractGUI) are a Java based user interface, you can use either one, although use of the newer SACDExtractGUI does require the latest version of the sacd_extract 3.9 in the package, only 3.9 will work and that is what Harold is referring to above, both he and I compiled that from sources on a Mac using the method described in Post #181.

Unfortunately, unlike with the Sonore ISO2DSD package, the newer SACDExtractGUI is not being offered (currently) as a simple complete download that is ready to use, you do have to compile the UNIX Executable component of that package yourself.

Are you planning to use Windows, Mac, or Linux to rip SACD?

EDIT: I looked back at your original post in this thread and see you are using a Mac, and that you did apparently already compile sacd_extract 3.9? If so you are all set to use the newer SACDExtractGUI, in place of ISO2DSD.
 
@MikeyFresh Well "Yee Haw" . It seems to be counting rip @ 2.3 Mb/sec . I was way back on firmware.
After reset I ticked boxes on or off as you described, updated firmware from like .004 (?) to the .50? The same one you upgraded to. It would not show provisioning until I upgraded firmware. I inserted usb stick and it opened. I took hdmi to monitor cable out and I have just completed my 1st Sacd to dff rip.
I averaged 2.9 Mb/sec . Then I had to copy sacd album I just made to my Audirvana drive. I then deleted ripped file from my (iso2dsd_OSX_v6) folder.
All shows perfectly as DSD64 being .dff files. When they play through Audirvana they indicated 24/88.2khz Stereo which is DSD.
I have to add how grateful I am to this topic and to all those who have posted problems that we were able to help each of us out. I am especially grateful to @MikeyFresh for having patience with my fumbling around like a fish out of water. He has been very dedicated in being extremely important to this thread.
I highly recommend before tackling this project to be well rested and patient or you may end up going around in circles like I did going nowhere.
Soon to be project will be Sacd Multichannel. I did try one and it finished but came out looking a sounding a little strange. Hang in anyone having trouble this is well worth to be able to archive collection. Especially for me since I listen primarily in my big comfortable chair with Headphone rig. Tom
:boogie
 

Attachments

  • back.jpg
    back.jpg
    896.3 KB · Views: 16
@MikeyFresh Well "Yee Haw" . It seems to be counting rip @ 2.3 Mb/sec . I was way back on firmware.
After reset I ticked boxes on or off as you described, updated firmware from like .004 (?) to the .50? The same one you upgraded to. It would not show provisioning until I upgraded firmware. I inserted usb stick and it opened. I took hdmi to monitor cable out and I have just completed my 1st Sacd to dff rip.

Outstanding Tom, way to stay at it!

So just like on my S390, yours too needed a firmware update before it would rip SACD. This is interesting in that other Sony models seem not to have that issue. I've only seen that reported on the S390, though I don't have all of the specifics as far as which early firmwares don't work and which version(s) do. I guess it's possible other Sonys could have the same issue too, but I've not seen anyone else report that except for just a couple of isolated instances with the S390.

All shows perfectly as DSD64 being .dff files. When they play through Audirvana they indicated 24/88.2khz Stereo which is DSD.

This is probably another case for us really needing a separate DSD playback options thread, to that end I've created one found here. But two quick questions:

1. Did you rip to .dff or .dsf? I ask because .dsf supports metadata such as appended album art where .dff does not, though maybe Audirvana keeps a separate album art cache of some sort to get around that?

2. What DAC are you using? 24/88.2 is actually transcoded to PCM, so check your Audirvana settings as the file is not being played back at it's native sample rate and DSD format if it does say 24/88.2, unless of course the DAC does not support DSD in which case you will need to transcode to PCM.
 
@MikeyFresh
1. Did you rip to .dff or .dsf? I ask because .dsf supports metadata such as appended album art where .dff does not, though maybe Audirvana keeps a separate album art cache of some sort to get around that.
Answer
I ripped to dff. I now remember you mentioning dsf contains metadata, so I will try that on the next one.

2. What DAC are you using? 24/88.2 is actually transcoded to PCM, so check your Audirvana settings as the file is not being played back at it's native sample rate and DSD format if it does say 24/88.2, unless of course the DAC does not support DSD in which case you will need to transcode to PCM.
Answer
My Dac is Matrix XSabre Pro. It does everything. All the way to DSD 512. When I was testing rips, I only used Audirvana and not my Dac yet. It was only with the Mac's dac.

I'm not sure of a custom cache for Audirvana. The multi-channel is something I would like to do next. I have a classical Sacd recorded in 1990 with 200 microphones that is stunning.
I'll be happy to follow up with anything. Please move anything or duplicate any info that could be useful to a separate topic.
I will get back with more comments when I have experimented more. Tom
 
When I was testing rips, I only used Audirvana and not my Dac yet. It was only with the Mac's dac.

Well that explains it then!

I've created a separate thread for further discussion on DSD playback options, both software and hardware discussion on actual DSD playback is invited there so as to keep this thread clean and focused on the actual SACD ripping task.

Once again, thanks for the feedback and congrats on ripping your first SACD.
 
This weekend I finally brought my Windows 10 laptop home from work in order to replace the beta versions of sacd_extract 3.9 and SACDExtractGUI that I've had on it since mid-September, with debugged versions compiled in late October.

While I already knew the debugged Mac version was working well for me, and I've seen various reports from other Windows users, it was time to update my own Windows machine and test it.

I also decided to test the speed/performance using WiFi only, so both the laptop and the Sony S5100 were connected via wireless. As expected, speed took a hit as compared to Ethernet LAN connection, but that's with an aging 802.11n spec'd WLAN, and both the laptop and Blu-ray player located downstairs, and the router upstairs a fair distance away. So all in all, not too bad speed-wise:

Win10-Extract.jpg
 
Can you document the procedure using Windows or even Linux as well? A lot to ask I know, but this is so concise and clear, it would be nice if we had instructions to cover all bases.

It is possible I could do it using Linux too, though I've never tried it before and there I'd be limited to Ubuntu on a Raspberry Pi, I'm not sure if that is a suitable hardware platform.

Linux is good. :)

It would be fun to get this working on a full Ubuntu install. :)

Epilogue?

My own testing of the new sacd_extract 3.9 and SACDExtract GUI came full circle tonight. While I'm happy to answer any questions from new or existing HFH members moving forward, and I encourage additional comments in this thread, I think tonight's post constitutes the end of my personal journey on this topic, as I have now finally successfully ripped an SACD using a Blu-ray player and the Linux platform.

This was all made possible (for me anyway) by the recent addition of support for ARM architecture processors in the fantastic sacd_extract 3.9.

So even though I still don't have a "proper" Linux box, now the humble and low-priced, low-powered Raspberry Pi3 b+ should work using the Raspbian Stretch OS variant of Debian Linux (I didn't test it, but I'm relatively sure it will also work on Ubuntu for RPi too). This I have.

For the record, the RPi3 b+ is the latest greatest version of that single board computer (SBC), and the Broadcom BCM2837B0 SoC employed has the following specs:

CPU: 1.4 GHz 64/32-bit quad-core ARM Cortex-A53
Memory:
1 GB LPDDR2 RAM at 900 MHz
Power:
1.5 W (average when idle) to 6.7 W (maximum under stress)

But would it run smoothly? Is the very limited horsepower on this $35 hardware sufficient only for "theoretically it will work", or will the little RPi3 once again over-perform relative to its meager specs and price point in ripping SACD?

Warning+massive+jojo+spoiler_b6ad11_6282295.gif

It works SUPER well!

The little RPi3 b+ barely broke a sweat both in terms of CPU and RAM utilization, or even heat generated, it actually ran cool to the touch (in an aluminum case):

Pi Task Manager.jpg

This RPi3 b+ is configured for network access via WiFi, both that and the aluminum casing in use (sub-optimal for WiFi reception) no doubt slowed the rip speed, but despite it all the process was smooth and only marginally slower than it is on Mac or Windows. Based on the low system resources utilized as shown in the screen shot above, I'd have to assume that a network connection via Ethernet might speed things up, as the RPi3 processing end does not appear to present any major throughput bottleneck. The rip result, while not setting any world speed records, was perfectly acceptable at 2.11MB/s.

Pi Extract.jpg

So that brings me full circle with ripping SACD using a Blu-ray player. With successful rips on Linux, Mac, and Windows, after several hundred total rips I'm now running out of titles that need ripping, though I still actively buy SACDs quite often and so will have newly acquired titles to rip for the foreseeable future.

If anyone wishes to have the step-by-step instructions for using an RPi3 to rip SACD, please comment in this thread and I'll post screen shots. It's not fundamentally different than on Mac or Windows, and there is actually one fewer set-up step involved because Raspbian Stretch Linux comes with the Java Runtime Environment already installed, unlike on the Mac or Windows operating systems.
 
Epilogue?

My own testing of the new sacd_extract 3.9 and SACDExtract GUI came full circle tonight. While I'm happy to answer any questions from new or existing HFH members moving forward, and I encourage additional comments in this thread, I think tonight's post constitutes the end of my personal journey on this topic, as I have now finally successfully ripped an SACD using a Blu-ray player and the Linux platform.

This was all made possible (for me anyway) by the recent addition of support for ARM architecture processors in the fantastic sacd_extract 3.9.

So even though I still don't have a "proper" Linux box, now the humble and low-priced, low-powered Raspberry Pi3 b+ should work using the Raspbian Stretch OS variant of Debian Linux (I didn't test it, but I'm relatively sure it will also work on Ubuntu for RPi too). This I have.

For the record, the RPi3 b+ is the latest greatest version of that single board computer (SBC), and the Broadcom BCM2837B0 SoC employed has the following specs:

CPU: 1.4 GHz 64/32-bit quad-core ARM Cortex-A53
Memory:
1 GB LPDDR2 RAM at 900 MHz
Power:
1.5 W (average when idle) to 6.7 W (maximum under stress)

But would it run smoothly? Is the very limited horsepower on this $35 hardware sufficient only for "theoretically it will work", or will the little RPi3 once again over-perform in ripping SACD relative to its meager specs and price point?

View attachment 8702

It works SUPER well!

The little RPi3 b+ barely broke a sweat both in terms of CPU and RAM utilization, and even heat generated, it actually ran cool to the touch (in an aluminum case):

View attachment 8703

This RPi3 b+ is configured for network access via WiFi, both that and the aluminum casing in use (suboptimal for WiFi reception) no doubt slowed the rip speed, but despite it all the process was smooth and only marginally slower than it is on Mac or Windows. Based on the low system resources utilized as shown in the screen shot above, I'd have to assume that network connection via Ethernet would speed things significantly. Still, the rip result was perfectly acceptable at 2.11MB/s.

View attachment 8704

So that brings me full circle with ripping SACD using a Blu-ray player. With successful rips on Linux, Mac, and Windows, after several hundred total rips I'm now running out of titles that need ripping, though I still actively buy SACDs quite often and so will have newly acquired titles to rip for the foreseeable future.

If anyone wishes to have the step-by-step instructions for using an RPi3 to rip SACD, please comment in this thread and I'll post screen shots. It's not fundamentally different than on Mac or Windows, and there is actually one fewer set-up step involved because Raspbian Stretch Linux comes with the Java Runtime Environment already installed, unlike on the Mac or Windows operating systems.

Outstanding result! :)

This tutorial should serve as a perfect guide for any audiophile who wishes to rip their SACDs to a hard drive for access and ease of use.

Please do post the screenshots of the Linux process. It is still on my "audio to do" list.

Thank you, @MikeyFresh - this has been a great benefit to our community. :)
 
I must say you have an awesome site here!

I need help!!

I have read, re-read, and read again just about every post here and cant seem to get this to work. I have a sony 5100 reset to default settings with Quickstart mode turned on. I power the 5100 up then insert the flash drive, the drawer opens, I insert a disc and power off. When the display stops flashing "off" I click on execute button in ISO2DSD. I have checked and double checked ip addresses but still get the error

"Failed to connect
libsacdread:Can't open 192.168.85.161:2002 for reading"

I have opened a command window and am able to ping the sony with no issues.
I have even tried running ISO2DSD on 3 separate computers with the same results.

Just to cover all bases - The 5100 does go online and is able to play files from my plex server so I know the network portion of this thing works (just never know with these ebay $25 purchases) so every aspect of the 5100 seems to work fine.

Thanks
Rob
 
Hi Rob,

Welcome to Hi-Fi Haven!

That error message suggests the port 2002 is somehow blocked, there can be any number of reasons for that.

Windows or Mac? Do you have some sort of anti-virus software, or other that could be blocking communication on port 2002?

If Windows, Post #127 might be of help too in the event you haven't already been through this aspect, but sometimes Windows Defender is the culprit for blocking port 2002.
 
I power the 5100 up then insert the flash drive, the drawer opens, I insert a disc and power off. When the display stops flashing "off" I click on execute button in ISO2DSD. I have checked and double checked ip addresses but still get the error

"Failed to connect
libsacdread:Can't open 192.168.85.161:2002 for reading"

Also please confirm that the USB thumb drive has an enclosing folder called AutoScript.

This has been a point of confusion for some folks and I can't fix it on the front end, as I am not the host of the DropBox cloud account where the AutoScript download takes place.

Suffice it to say the DropBox interface is a little bit confusing, resulting in people downloading the contents of the AutoScript enclosing folder, rather than the actual enclosing folder itself.

If you don't have an enclosing folder and just downloaded the 3 individual files comprising it's contents, no big deal, you do not have to re-download anything, simply create an enclosing folder on the USB thumb drive called AutoScript, and place the previously downloaded contents inside of it.

Alternatively, if you wish to start over fresh with the AutoScript (not a bad idea if you've gone poking around inside of any of those items), just do this:

DropBox.jpg

The resulting downloaded AutoScript folder should go on the USB thumb drive at the root level, and delete the previously placed individual files (assuming that's what occurred).
 
Back
Top