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

[Dick Darlington]

5 minutes ago, Phthalocyanine said:

The Sony uses sacd_extract_160 so that has to be referred to.  You have the version for the Oppo which lists sacd_extract.

 

Great catch!

 

FWIW I’ve played around and had success with a script that attempts to launch Telnet both ways. One succeeds the other fails. And it runs both sacd_extract and sacd_extract_160. So basically it works for both local and server ripping on both the Oppo and the Sony. Of course for local ripping I have to manually kill the server mode sacd_extract* and relaunch it within the Telnet command console. So basically this is what I use personally and even though I generally use the GUI sacd_extract, I can always open a Telnet session if I want and it doesn’t matter which player model sparks joy on any given day. 

[Dick Darlington]

9 minutes ago, Phthalocyanine said:

Let me politely beg to differ on this point.

 

The lines of the script he has

 

CLI(CLI_exec cp /mnt/sda1/AutoScript/sacd_extract /)
CLI(CLI_exec /sacd_extract -S &)

 

do precisely copy sacd_extract to the root of the player and then launch it.

 

ATM I’m inclined to think I must have misread something and I definitely missed the missing _160 part which indeed must be the answer. 

 

That said the way I read it, he tried two scripts but was attempting the server method in both cases. It looks as if the (a) script does the cp line and launches the binary whereas the (b) script does not but rather runs telnet and scrolls the message.  It was the (b) script that I was referring to in terms of not working with @tmtomh‘s non-Telnet procedure. 

 

If I buggered this up, I apologize and my only excuse is that I’m currently on a small form factor mobile version of the site. How lame is that!? 😉 

[Phthalocyanine]

36 minutes ago, Nexus3 said:

@ted_b I think your offer comes at the most perfect time, as the "problems" @BACHJS ran into show that there is a need (especially among freshmen) to have the script and ripping-method landscape consolidated.

 

 

Shall we re-create the 3 main scripts for remote ripping adding a readme.txt featuring e.g. the supported player models and the basic steps?

I think there needs to be a link at the beginning to a central repository (like a public dropbox) that has all the versions of all the scripts and programs needed and all the documentation for the various methods.  Currently @ted_b and @Dick Darlington are hosting public dropboxes which have various versions of the scripts and the documentation.  So some initial questions are who (perhaps both) will maintain that public repository, and how to arrange the materials in a way that one can easily send a newbie to the right sources for their player and method.

[Dick Darlington]

1 minute ago, Phthalocyanine said:

I think there needs to be a link at the beginning to a central repository (like a public dropbox) that has all the versions of all the scripts and programs needed and all the documentation for the various methods.  Currently @ted_b and @Dick Darlington are hosting public dropboxes which have various versions of the scripts and the documentation.  So some initial questions are who (perhaps both) will maintain that public repository, and how to arrange the materials in a way that one can easily send a newbie to the right sources for their player and method.

 

I volunteer to be the subservient grunt hosting files but not the curator. 

 

Gee now who in the world <subliminal @Phthalocyanine> could we court for the latter role? 🤔 

[Phthalocyanine]

21 minutes ago, Dick Darlington said:

That said the way I read it, he tried two scripts but was attempting the server method in both cases. It looks as if the (a) script does the cp line and launches the binary whereas the (b) script does not but rather runs telnet and scrolls the message.   It was the (b) script that I was referring to in terms of not working with @tmtomh‘s non-Telnet procedure.

Yes, but the way I understand it (in my admittedly non-programmer way) is that you need  things to happen that are in both scripts to get any server method to work.

 

You need the parts of the scripts that take root control of the player, copy the sacd_extract or sacd_extract_160 binary to root and launch it in server mode, thereby opening up the network connection.  You don't strictly speaking need to open telnet connection for the server method to work, but in the stock scripts that command is there right after the get control of password and root command that you do need.

 

It is totally inelegant but that is why there have been two folders with two scripts.  Between the two of them they do everything you could want.  A more elegant script solution could be done for particular methods, which is what you have been doing.

[Phthalocyanine]

5 minutes ago, Dick Darlington said:

Gee now who in the world <subliminal @Phthalocyanine> could we court for the latter role? 🤔 

I'd be happy to take a role in that but I would defer to advocates for particular methods like sleep-server to decide what their model scripts would be and what their model documentation should be.  Programmers like @mindset and @Dick Darlington might agree to review model scripts for technical soundness.

[Phthalocyanine]

@BACHJS

Sorry if I ended up digressing on some technical points with Dick D.

To solve your current situation this is what you need to know and do.

The same file folders and their content that you used successfully to rip with your Sony S590 with the telnet/local ripping method  - you use those very same file folders and their contents for the sleep server method.

But you use a different method that does not require the use of telnet.  And you use different settings (like enabling quick start mode).  So follow the appropriate guide for sleep server method to the letter.

 

On another front, @BACHJS PM-ed with another problem he was having that I have never seen before.

 

 

 

His ripping truncated at 6% with the error message: secBus error.

My first guess is that the drive is having a problem reading a sector of the disc - but whether that is because of the drive or the disc is not clear.

I suggested that he try other SACD discs to see whether it is the disc or the drive.

 

[Phthalocyanine]

For organizing the materials for the master SACD ripping repository, I was thinking of the following.

In an introductory READ ME FIRST section, we would have a grid chart.

 

On the vertical row we would have the names of the various useable players:

 

Oppo 103

Oppo 105

Sony BDP S390

Sony BDP S590

Sony BDPS790

etc.

 

On the horizon row we would have the names of the three main ripping methods:

 

1.  Telnet/Local Ripping to USB (including Telnet troubleshooting)

2.  Awake-Server Method

3. Sleep-Server Method

 

In the contents of the grid we would have a letter or number or a descriptive name for a folder, to which one would then go to find all the needed scripts, correct version of sacd_extract linux binary, and detailed documentation.

I have not worked out all the possible combinations yet, but they will not be that many.  Many different players will use the contents of the same folders.  (For example, the majority of the Sony players except for the newly discovered Arm 7 models, will use the same acripts and version of sacd_extract for each of the various methods.)

[mindset]

12 hours ago, Nexus3 said:

 

@mindset, do you still own the BDP-6500 & BDP-6700 models and able to re-check their SACD ripping abilities? 🤞

No luck there due to kernel version mismatch.

[Dick Darlington]

12 hours ago, Phthalocyanine said:

You need the parts of the scripts that take root control of the player, copy the sacd_extract or sacd_extract_160 binary to root and launch it in server mode, thereby opening up the network connection.

 

The AutoScript actually has root control of the player the moment it is launched. The line appending the string containing root to the passwd file is what allows root to establish an interactive session without a password via telnet. Assuming the telnet daemon is launched of course.  Speaking strictly to the server method, that line if present is superfluous. 

 

In fact the AutoScript need only contain two lines to facilitate server mode ripping:

 

CLI(CLI_exec cp /mnt/sd*/AutoScript/sacd_extract /)

CLI(CLI_exec /sacd_extract -S &)

 

Thats it. All those other line are fluff albeit some are useful e.g. the scrolling display as a confirmation that the AutoScript launched. The two line script above worked beautifully on my Oppo and the same having the “_160” appended to sacd_extract works on my Sony. 

[Dick Darlington]

1 minute ago, Dick Darlington said:

Thats it. All those other line are fluff albeit some are useful e.g. the scrolling display as a confirmation that the AutoScript launched. The two line script above worked beautifully on my Oppo and the same having the “_160” appended to sacd_extract works on my Sony. 

 

It has long been a quandary for me to adopt a position considering all factors on which approach is best: a repository of myriad officially blessed bare bones scripts; each optimized for a specific player / use case scenario. Or alternatively as few as possible robust scripts capable of handling a large subset of the permutations universe. I used to lean toward the latter but somehow that no longer sparks joy. 🤷🏼‍♂️

 

I think the key to the former is a well thought out and intuitively navigable organization scheme along the lines of what @Phthalocyanine has been waxing on.

[Phthalocyanine]

3 hours ago, Dick Darlington said:

The AutoScript actually has root control of the player the moment it is launched

Ah, that's the part I never really understood.  So thanks for clarifying that!.☺️

 

(I'll purse further technical clarification by PM with you, so as to not get too OT.)

[ted_b]

I had Chris give Phthalocyanine editing/curating capability.  Not sure what that entails, so guys let me know if I need to do anything.  I am also happy to take down any confusing or redundant dropbox links, once Dick Darlington establishes a comprehensive one.  Thx

[Nexus3]

20 hours ago, Phthalocyanine said:

For organizing the materials for the master SACD ripping repository, I was thinking of the following.

In an introductory READ ME FIRST section, we would have a grid chart.

 

On the vertical row we would have the names of the various useable players:

 

Oppo 103

Oppo 105

Sony BDP S390

Sony BDP S590

Sony BDPS790

etc.

 

On the horizon row we would have the names of the three main ripping methods:

 

1.  Telnet/Local Ripping to USB (including Telnet troubleshooting)

2.  Awake-Server Method

3. Sleep-Server Method

 

 

In the contents of the grid we would have a letter or number or a descriptive name for a folder, to which one would then go to find all the needed scripts, correct version of sacd_extract linux binary, and detailed documentation.

 

 

I have not worked out all the possible combinations yet, but they will not be that many.  Many different players will use the contents of the same folders.  (For example, the majority of the Sony players except for the newly discovered Arm 7 models, will use the same acripts and version of sacd_extract for each of the various methods.)

 

 

Hello @Phthalocyanine, is this Google spreadsheet similar to what you had in mind? Though it is just a starting point, fell free to copy, modify or correct it.

 

 

 

[Phthalocyanine]

1 hour ago, Nexus3 said:

is this Google spreadsheet similar to what you had in mind?

Yes that is a good start!

[BACHJS]

On 2/25/2019 at 7:43 PM, Phthalocyanine said:

@BACHJS

Sorry if I ended up digressing on some technical points with Dick D.

To solve your current situation this is what you need to know and do.

The same file folders and their content that you used successfully to rip with your Sony S590 with the telnet/local ripping method  - you use those very same file folders and their contents for the sleep server method.

But you use a different method that does not require the use of telnet.  And you use different settings (like enabling quick start mode).  So follow the appropriate guide for sleep server method to the letter.

 

On another front, @BACHJS PM-ed with another problem he was having that I have never seen before.

 

 

 

His ripping truncated at 6% with the error message: secBus error.

My first guess is that the drive is having a problem reading a sector of the disc - but whether that is because of the drive or the disc is not clear.

I suggested that he try other SACD discs to see whether it is the disc or the drive.

 

Hello to all,

 

Latest report on my attempts:

 

SUCCESS ! 

 

Finally, I have been able to extract many SACDs in a row. After many tests and false trials, I purchased a new USB stick, copied @Phthalocyanine's recommended AutoScript folders and files, and followed the guide step by step. And, it worked... I repeated the operations today to see if I was able to replicate it and it also worked. The new USB key is a ScanDisk Cruzer Glide 32 GB (FAT32) which I used as purchased. I only copied the AutoScript folders in it. It worked at my first trial.

 

Thanks to those who helped me a great deal in getting there.

 

Now, using the same USB stick with the exact same AutoScript files, I tried the network method with the player Quick Start option selected. I followed line per line the methodology recommended to me by one of you. I used both ISO2DSD and SACDExtractGUI without being able to  connect via the 2002 port and get the process while the machine was at sleep. I have certainly misinterpreted the instructions. The only area where I am not sure if I understood correctly is when they say in the instructions in the very first step: "Ensure the SACD ripping GUI app and the SACD ripping executable are both together in the same folder/directory on your computer". Do I have to copy the "sacd_extract_160" program there???. I took for granted that each of the GUIs have their own executable program bearing the "exe" extension present in their specific directory. This is where, I am uncertain. Or, I got everything wrong starting with the proper AutoScript files I need to use.

 

As a newbie who struggles, I fully support your efforts to present all the resources available in one unique place. What I have seen so far, above, is excellent.

 

Regards,

 

B.

[Phthalocyanine]

38 minutes ago, BACHJS said:

Do I have to copy the "sacd_extract_160" program there???.

No this is a common confusion.

You need to have the windows sacd extract.exe program.

The three you need together look like this.  (It should just be sacd.extract.exe - ignore the x in the name here.  Too hard to explain.)

[Nexus3]

37 minutes ago, Phthalocyanine said:

1 hour ago, BACHJS said:

Do I have to copy the "sacd_extract_160" program there???.

No this is a common confusion.

 

Mhh, how about metaphor?

 

Quote

 

sacd_extract.exe (+GUI) 

is the queen bee, staying in the hive (=PC).

 

sacd_extract
sacd_extract_160
sacd_extract_6200

are the working bees, spreading out to collect pollen (=DSD) from various flowers (=blu-ray players).

 

 

 

 

 

 

On another topic:

 

It might be a long shot and not worthwhile checking, considering SACD playback is not spec-listed nor advertised as a feature for the Sony BDP-S190.

But its firmware is compatible to the bigger sister models BDP-S390 & BDP-BX39. 
Additionally the service manuals prominently carry the SACD logo.

 

 

 

[Dick Darlington]

1 hour ago, BACHJS said:

Now, using the same USB stick with the exact same AutoScript files, I tried the network method with the player Quick Start option selected.

 

Are you saying that you used the same script that had just worked for you to rip locally to the usb stick via Telnet in your subsequent attempt to rip over the network via the GUI app on your computer?

 

Not sure I’m reading this right. Chances are I’m misunderstanding but most scripts set up for local ripping don’t support server method ripping and vice versa. 

[Phthalocyanine]

21 minutes ago, Dick Darlington said:

Chances are I’m misunderstanding but most scripts set up for local ripping don’t support server method ripping and vice versa. 

Yes, a script specifically tailored only for local ripping would not support server method ripping.

 

But he was using the old stock scripts contained in both the  Autoscipt and AutoscriptSACD folders.  You can do both with those.  But terribly hacky and untailored.

 

When we get everything sorted out and have tailored scripts for each method and player and a way of sending people to the right resources, this wont be a problem.

 

In the meantime, can some advocate for the sleep-server method (maybe @tmtomh) please PM @BACHJS the actual script files you use, so we can rule this out as his problem.

 

And just to be clear -- @BACHJS Which method were you successful with in your last post?  and which method are trying to master?

[BACHJS]

@Phthalocyanine To answer your question: I used successfully the telnet method as layed out in your guide with the proper scripts (I guess...).

 

Later or, I tried to use the same scripts to test the other ripping method using GUIs with sleep mode activated as I thought that what you suggested in your earlier post (above: Monday, 7:43 pm) when you wrote to me:

 

"To solve your current situation this is what you need to know and do.

The same file folders and their content that you used successfully to rip with your Sony S590 with the telnet/local ripping method  - you use those very same file folders and their contents for the sleep server method.

But you use a different method that does not require the use of telnet.  And you use different settings (like enabling quick start mode). "

 

Ripping SACD via the netword in sleep mode seems to me an interesting option since one can decide in what format to obtain the files. I would then save a step in avoiding the extraction of the ISO content to dsf files. Maybe I can achieve this in using the telnet option -s instead of -I as suggested by the help of the executable sacd_extract_160 file. I will try that later on.

 

B.

[Dick Darlington]

6 minutes ago, BACHJS said:

@Phthalocyanine To answer your question: I used successfully the telnet method as layed out in your guide with the proper scripts (I guess...).

 

Later or, I tried to use the same scripts to test the other ripping method using GUIs with sleep mode activated as I thought that what you suggested in your earlier post (above: Monday, 7:43 pm) when you wrote to me:

 

"To solve your current situation this is what you need to know and do.

The same file folders and their content that you used successfully to rip with your Sony S590 with the telnet/local ripping method  - you use those very same file folders and their contents for the sleep server method.

But you use a different method that does not require the use of telnet.  And you use different settings (like enabling quick start mode). "

 

Ripping SACD via the netword in sleep mode seems to me an interesting option since one can decide in what format to obtain the files. I would then save a step in avoiding the extraction of the ISO content to dsf files. Maybe I can achieve this in using the telnet option -s instead of -I as suggested by the help of the executable sacd_extract_160 file. I will try that later on.

 

B.

 

Can you please post the contents of the script you are using for your server mode attempts?

 

Reason being that I want to confirm it is launching sacd_extract(?) in server mode. If it’s not it can’t work. Otherwise the problem is elsewhere. 

[Phthalocyanine]

4 minutes ago, BACHJS said:

I thought that what you suggested in your earlier post (above: Monday, 7:43 pm) when you wrote to me:

Yes and I stand by that, since I have used the same original scripts and folders for all the methods.  But if it causes less confusion, it might be better for you to use the scripts that some dedicated sleep-server users are using, so to eliminate the possibility that your current problem is because of the scripts.

 

7 minutes ago, BACHJS said:

Maybe I can achieve this in using the telnet option -s instead of -I as suggested by the help of the executable sacd_extract_160 file. I will try that later on

Yes, you can use any of the extraction options in telnet command line method that you can in the server method.  Conventional wisdom is that it is best to extract a full .iso from your ripping player and then do other extraction with iso2DSD on your Windows or Mac Computer.  Less wear and tear on your ripping player for instance.  This was more of a consideration when the PS3 was the only ripping possibility and it was expensive and tended to overheat and wear out with too much use.

 

Usage: sacd_extract_160 [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
  -S, --server-mode               : start in a server mode

Help options:
  -?, --help                      : Show this help message
  --usage                         : Display brief usage message

[BACHJS]

@Dick Darlington:Here are the scripts:

 

in files of the AutoScript folder :

 

#MTKAT 0.xx script

CLI(CLI_exec echo root::0:0:root,,,:/root:/bin/sh >/etc/passwd)
CLI(CLI_exec /usr/sbin/telnetd &)
SLEEPMS(3000)
CLI(CLI_app.vfdmg.b clear_msg)
CLI(CLI_app.vfdmg.b scroll_msg start)
SLEEPMS(5000)

 

In files of the AutoScriptSACD folder 

 

#MTKAT 0.xx script
 
CLI(CLI_exec cp /mnt/sda1/AutoScript/sacd_extract_160 /)
CLI(CLI_exec insmod /lib/modules/2.6.35/BDP/splitter.ko)
CLI(CLI_exec /sacd_extract_160 -S &)
CLI(CLI_drv.ir.rx.sq 0xaf000)

 

B.

 

 

 

[Phthalocyanine]

1 hour ago, Nexus3 said:

the Sony BDP-S190

Wow you are beating the bushes to find some rare Sony models!

This was marketed in Brazil and where else?

So you think this is essentially (or firmware-wise completely) a S390?