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

[mindset]

10 minutes ago, BluRay444 said:

mindset said "I do not know what you were getting that old version of sacd_extract."

I did mention I got it from Ted_B's Autoscript (in this thread), how could you tell that it was an old version of sacd_extract?

That is a little difficult one.  I believe the only publicly available version-controlled sources of sacd_extract executable are here: https://github.com/sacd-ripper/sacd-ripper/releases  and the one in iso2dsd.  Perhaps you can compare md5sum of your executable with these?

 

14 minutes ago, BluRay444 said:

I think the bottom line is that when I extract files from SACD's, I only need the DSF version because it's uncompressed  DSD (which is what I want) and has better native support for metadata (DFF can store metadata ID3 format in the DFF's internal data block, but the DFF file player must also be capable of recognizing ID3 chunks).

Have I got it right?

Absolutely!

[mindset]

2 hours ago, Nexus3 said:

 

@mindset How feasible would it be to implement the following arguments for better version information and source origin?

 

  -v, --version			  : shows official version number
  -gr,--git-repo		  : displays the git repository from which the source package originated
  -gp,--git-patch-date		  : states the date of the latest patch comitted to the sources

 

Yes, it's most likely feasible.  Will try implementing something like that. 

[mindset]

13 minutes ago, Nexus3 said:

 

 

IT WORKS with the GUI !

 

Extraction (and conversion to DSF) rate was well over 2 MB/sec for a stereo only SACD.

Great.  For direct DSF generation from a disc, it should go as fast as ISO extraction (around 3MB/s) on a fast enough computer, which the original didn't.  Maybe there is a slow wifi bottleneck somewhere between your computer and the player?

 

[mindset]

On 9/15/2018 at 11:28 AM, Nexus3 said:

 

@mindset How feasible would it be to implement the following arguments for better version information and source origin?

 

Done now & pushed to github.  I just added a -v option which gives sufficient info.  It shows the tag name and commit hash (if the commit has no tag). Also fixed the problem that a cue sheet is not exported with -s and -p.

 

For commit with tag:

$ ./sacd_extract -v
sacd_extract version 0.3.9@setmind
git repository: "https://github.com/setmind/sacd-ripper.git"

 

For a commit without a tag (1 commit ahead of the last tag):

$ ./sacd_extract -v
sacd_extract version 0.3.9@setmind-1-gaeb9d1acda3c4779fa8e3d56c72ffab394d184d4
git repository: "https://github.com/setmind/sacd-ripper.git"

 

[mindset]

On 9/8/2018 at 1:19 PM, mindset said:

To users of sacd_extract using the server method:

 

I have been working on improving the sacd_extract client program from the currently inactive original sacd-ripper repository past few months.  I thought I would share that in case someone is interested.  Here is the git repository: https://github.com/setmind/sacd-ripper/  (Sorry, you need to compile the code to use it).

 

In addition to performance improvement and bug fixes, I have added features like concurrent extraction of ISO and DSF/DSDIFF in a single scan of a disc, padding-less DSF generation for some players that cannot handle DSF tail padding properly, extraction of multi-channel and single-channel tracks in one shot, and addition of more ID3v2 tags from TOC to DSF.  Details with compilation instruction are described in https://github.com/setmind/sacd-ripper/blob/master/readme.rst and performance comparison with the original is here https://github.com/setmind/sacd-ripper/wiki

 

I have just acquired a cheap mac, and confirmed this works fine without any change on mac as well (both in command line and Sonore's GUI).

 

Compilation is fairly easy:

xcode-select --install
/usr/bin/ruby -e "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install)"
brew install cmake
git clone https://github.com/setmind/sacd-ripper.git
cd sacd-ripper/tools/sacd_extract
cmake .
make

This yields a sacd_extract executable, and it can replace the original in Sonore's package.  I am seeing significant performance improvement over the original (~4x speed boost for ISO->DSF).  Speed improvement is less for direct generation of DSF from the server as that is limited by the player's optical drive.

 

I am currently working on a new GUI that can support all new features in sacd_extract.

 

[mindset]

4 hours ago, Nexus3 said:

Time to undust my PowerMac G5 then ?.

That is a really old Mac.  I am sure you will encounter problems because it's not Intel-based.

 

[mindset]

14 minutes ago, MikeyFresh said:

In fact, I believe I saw a speed increase even though I rip directly to .dsf. Could that be a coincidence? I guess it could, I have no direct point of comparison in the form of speed data on a previous rip of that very same disc having been slower as it's the first time I've ever ripped this disc.

 

Thanks for the feedback.  That is actually not a coincidence but part of these improvements:

 

1. Maximum compiler optimization for much faster DST decoding (was a really low-hanging fruit)

2. Parallelizing read from disc and DST decoding

 

In your case, I believe DST decoding was already fast enough because you have a powerful machine so 1. didn't do much.  2. probably gained a little bit of speed improvement (I expected a bit more though) and got you very close to the player's speed limit of around 3MB/s (depending on the disc).  

 

On my old Mac mini 2010, 0.55MB/s from the original in Sonore got boosted to 2.04 MB/s for direct extraction of DSF from a player.

[mindset]

1 hour ago, Triplefun said:

Why are you focusing on all these alternative extract programs when the free sonore iso2dsd seems to do everything that is required? Am I missing something?

Sonore's ISO2DSD may be doing everything you need, but some people like me have unique needs.

 

Just to give you my example:

 

I receive a disc from Amazon.  I put the disc in the player and and ask sacd_extract to extract ISO to a NAS and DSF to SONY HAP-Z1ES in a single scan of a disc.  6 minutes into the process (was 15 mins with the original) the stereo portion of the disc has been read and is ready for listening while the program continues to read the multi-channel section of the disc to finish the ISO.

 

This is not possible with the original, and  is the reason I started working on the improvements.

[mindset]

2 minutes ago, Nexus3 said:

but then this struck:

@mindset

I might be able to cope with "__mm_malloc", but what about the other two - any ideas?

 

That is a solvable problem.   Try this: https://github.com/sacd-ripper/sacd-ripper/issues/98  I might incorporate this to my code.

 

[mindset]

1 hour ago, MikeyFresh said:

I deliberately chose two RCA Living Stereo titles for this test as I have noted over time for some reason the discs in that series tend to rip slower than most others, I don't know why that is but it's a trend for sure from my experience.

Great to hear that the program worked well for you.  The reason that particular disc rips slower than other discs is probably that it has a smaller total playing time than other discs. The optical drive on the player seems to read at a constant angular velocity (constant RPM in other words) so its output data rate increases as the optical head moves away from the center of the disc.  When the total playing time is small, most of the time is spent near the center of the disc so the data rate is slower than other discs that use more outer region of the disc.

 

You can try ripping the same disc in stereo and multi channel.  You will see that the multi channel section rips faster (in MB/s) because it uses the outer section of the disc.  The last track of the multi channel section rips fastest.  For example, the first track of stereo rips around 2.1 MB/s while the last track in multi channel rips at around 3.4 MB/s for the disc I tried.

 

[mindset]

On 9/22/2018 at 3:00 PM, mindset said:

I am currently working on a new GUI that can support all new features in sacd_extract.

 

 

I am currently working on this.  I should be able to release this soon.  It will work in Linux/Windows/macOS.

 

[mindset]

27 minutes ago, BluRay444 said:

I get that the mac version of SACD_EXTRACT has to be compiled on the mac using it due to it not being developer-signed (at least that's my understanding, perhaps crudely explained), but what about providing a checksum to confirm that it had been properly compiled, would that be possible?

I am not sure about the signing part as I am not very familiar with the mac ecosystem. 

 

Checksum of a binary depends on many factors like the version of compiler, so it will not be useful for confirmation of proper compilation.  Since compilation of sacd_extract binary is not that difficult, those who care about the integrity of the binary should just get the source codes from github and compile them without any modification.  The source codes on github are rigidly version-controlled.

 

[mindset]

23 minutes ago, BluRay444 said:

I'm not sure if the resulting file is a stand-alone and I can uninstall the compilation tools or if the files in the final directory are dependencies.

I am pretty sure the compiled program has no dependency on items under the source tree, but not sure about dependency on the compilation tools  (I doubt it though).  If you care, you can try removing the source tree and the compilation tool to see what happens.

[mindset]

On 9/30/2018 at 1:06 PM, mindset said:

I am currently working on this.  I should be able to release this soon.  It will work in Linux/Windows/macOS.

 

This was just released at https://github.com/setmind/SACDExtractGUI/releases

Please note that this doesn't come with a sacd_extract executable, and is meant for sacd_extract@setmind (https://github.com/setmind/sacd-ripper) NOT the original by mrwicked.

 

SACDExtractGUI.jar is the Java executable.  If it cannot be invoked from the OS GUI, try this in the terminal:

java -jar SACDExtractGUI.jar

At minimum, you need to specify path to the sacd_extract (sacd_extract.exe for Windows) program at the top of the GUI. I believe the rest is pretty much self-explainable.

 

 

[mindset]

2 hours ago, haggis999 said:

'cmake' is not recognosed as an internal or external command, operable program or batch file.

 

Where do I go from here?

I assume you are trying to compile sacd_extract@setmind on Windows.  If you are using Windows 10, I would recommend using WSL (Windows Subsystem for Linux) which provides Linux environment on Windows.  Native Linux is fine, too. 

 

The compilation instruction is meant for Linux, and getting a tool chain lined up in Windows for a program like this is not very straight forward.

[mindset]

1 hour ago, MikeyFresh said:

Now there is less guess work or necessary checking through various different means, from mindset's new GUI you can quickly check to see if the Blu-ray player can be Pinged (or not), and also Test whether Port 2002 is accessible (or not) .

 

The above will go a long way towards solving issues, helping point in the right direction for additional troubleshooting steps, or, if it looks like it does above then just rip away!

Thank you for highlighting this.  Yes, this was another reason I wanted create the new GUI after seeing many troubleshooting posts.

[mindset]

Just now, haggis999 said:

 

I've now enabled the "Windows Subsystem for Linux" optional feature of Windows 10. Do I also need to install one of the several varieties of Linux? If so, which one would you recommend? How do I then open the appropriate command line interface?

Great.  I believe you have to install one of the Linux distributions.  I use Ubuntu both on WSL and native.  You should get an icon to enter the command line interface after installing it.

[mindset]

4 minutes ago, haggis999 said:

 

I gave that a try, but this prompted the following error messages.

 

E: Failed to fetch http://security.ubuntu.com/ubuntu/pool/main/1/linux/linux-libc-dev_4.15.0-29.31_amd64.deb 404 Not found [IP:  .....]

E: Unable to fetch some archives, maybe run apt-get update or try with --fix-missing?

 

Try this:

sudo apt update

 This updates the pointer to package repositories to the latest one.

[mindset]

30 minutes ago, haggis999 said:

 

Running that update process, followed by sudo apt install cmake, resolved those problems. Thanks for that, but now I need some guidance on how to use cmake under Ubuntu (just running cmake without any parameters does nothing useful). 

 

EDIT:  I have also followed Richard's advice to run 'sudo apt-get upgrade'.

I believe you are trying to compile an executable for Windows.  In that case follow the instruction around the end of https://github.com/setmind/sacd-ripper/blob/master/readme.rst .  It is expected that cmake does nothing if you don't pass any parameter.   libiconv mentioned in the instruction is here https://ftp.gnu.org/gnu/libiconv/

 

EDIT: This one is a better instruction: https://github.com/setmind/sacd-ripper/wiki#windows-using-native-linux-or-windows-subsystem-for-linux

[mindset]

3 hours ago, haggis999 said:

In the hope that I am doing the right thing, I have proceeded with the above-mentioned instructions. I have reached the point where I run 'make' for libiconv. This has now completed, with several purple warning messages that have now scrolled off the Ubuntu screen, but there were also the following errors near the end. Note that haggis999 is my Ubuntu username.

 

libtool:  error: Could not determine the host path corresponding to

libtool:  error:   '/home/haggis999/libiconv-1.15/lib/.libs'

libtool:  error: Continuing, but uninstalled executables may not work. 

libtool:  error: Could not determine the host path corresponding to 

libtool:  error:   '/home/haggis999/libiconv-1.15/lib/.libs:/usr/x86_64-w64-ming32/lib:/usr/x86_64-w64-ming32/bin'

libtool:  error:  Continuing, but uninstalled executables may not work.

 

EDIT:  I did try continuing with the instructions, but the compilation of sacd_extract was terminated with a fatal error:

 

iconv.h: No such file or directory

  

 

I just tried uninstalling & installing Ubuntu on WSL, and went through the instruction to make sure I am not missing anything.  I got those errors from libtool, but just moved on and got sacd_extract.exe generated successfully.

 

That error with iconv.h makes me think that you might have skipped "sudo make install" for libiconv.

[mindset]

17 minutes ago, haggis999 said:

EDIT:  My first rip to both stereo and multi-channel paddingless DSFs took about 16 1/2 mins, which I'm sure is several minutes faster than with ISO2DSD. The stereo rips were completed before the multi-channel rips started, so the process is sequential rather than simultaneous.

Somebody submitted a fix for that to github recently, but the executable you got had been probably created before that.  If you had succeeded in compiling sacd_extract, you would have picked the latest which includes that fix.

 

[mindset]

7 minutes ago, klassikmann said:

Second,  in the SACDExtractGUI for processing "DSDIFF edit master" the checkbox "DST decompression" is greyed-out. This seems not to be correct.

Thanks for pointing that out.  Will fix that soon.

[mindset]

13 minutes ago, servoyguru said:

should the Linux version work on Mac?

No.  There is no compatibility between Mac and Linux executables.

[mindset]

9 hours ago, mindset said:

Thanks for pointing that out.  Will fix that soon.

Fixed.  Current version: v0.1-3-g0d9165b0

 

[mindset]

6 hours ago, haggis999 said:

I have just re-ripped that same SACD using my previous ISO2DSD process. It took just under 22 mins to rip it in both stereo and multi-channel mode. That means SACDExtractGUI + sacd_extract 0.3.9 provided a worthwhile time saving of over 5 mins. If the later version of sacd_extract.exe can speed that up even more by running stereo and multi-channel rips in parallel then so much the better.

It won't be any faster.  You are most likely limited by the player side's optical drive.  Plus, stereo and multi-channel cannot be read in parallel.  They are recorded at two separate locations and there is only one optical head in the drive.