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

[mindset]

14 minutes ago, Phthalocyanine said:

So you ended up using sacd_extract 160 even though it is compiled for Arm 6 on the Sony S6200 which is running Arm 7 but the added kernel module made it work?

 

When you have the time, please try to explain this in simple terms to us simple minds out here.  ☺️

The sacd_extract_160 "program" itself is compatible with both ARMv7 and ARMv6.  It's the kernel module file embedded in the binary that is kernel-dependent.  Therefore, sacd_extract_160 program works fine if the kernel module extracted sacd_extract for Oppo, which carries the kernel module for ARMv7, is loaded before running sacd_extract_160.

 

By the way, I tried running sacd_extract for Oppo with libiconv.so.2 you sent me on S6200.  It worked fine, too.  I think this is less hacky and better approach than playing with kernel modules like I was doing a few minutes ago.  All I had to do was to put it it in the same directory with sacd_extract.  I am doing all this experiments in telnet.  Not sure if we can make this work automatically via Autoscript

 

To summarize:

 

BDP-S5100, S4100, S590, and S490 use ARMv6 and are missing libiconv.so.2

BDP-S6200 and BDP-S790 use ARMv7 and are missing libiconv.so.2

(S790 is not fully confirmed yet, but most likely same as S6200)

 

sacd_extract_160 doesn't have libiconv.so.2 problem, and carries sacd_read kernel module for ARMv6

sacd_extract for oppo has the libiconv.so.2 problem on Sony's, and carries sacd_read kernel module for ARMv7

 

 

[hyendaudio]

6 hours ago, Phthalocyanine said:

It doesn't matter if you have other stuff on the Thumbdrive.  If you have the right Autoscript folder in the root with the right files then it will work.  So that's not your problem.

 

OK check the scripts in the files against the content described in my guide at the end.  (Open Autoscript and Autoscript TSS  in Notepad.)

Because if the right scripts are running correctly you should be able to get telnet access.  This is where your problem may be.

 

The fact you got connection refused means that Putty did find s device at the address you entered.  But does the Pioneer have a setting in its setup menus where you can -check its IP address? 

 

Hi Phthalocyanine

 

D'uh. RTFM LOL. I missed the appendix first time around, but saw it then your very polite and gentle suggestion. I have updated the autoscript and autoscript.tss files with the new content and now the player boots and briefly displays ABCDEFGHIJK then goes dark and the tray no longer opens. Putty and iso2dsd still fail with the same error - even after I manually opened the tray and inserted an SACD. I also noticed there is reference to a second folder called autoscriptSACD with the same set of 3 files, although autoscript and autoscript.tss both appear to have the same content as the original version I replaced in autoscript. Despite there being no other reference that I've found regarding autoscriptSACD, I created a second folder and installed these 3 files with the updated commands and tried again. Same as noted previously: Scrolling alphabet then dark and door no longer opens on its own. More importantly putty and iso2dsd still yield the same response. 

 

I used to be an SA and deployed Sun workstations and servers (also Netware, 3Com Etherseries and Windows, IBM Xenix & UNIX, HPUX and DEC) all over the world and I'm feeling quite dumb at the moment. Guess I just dated myself 😶. So what am I doing wrong?

 

Thank you again for your time, patience and assistance!

[mindset]

32 minutes ago, mindset said:

I am doing all this experiments in telnet.  Not sure if we can make this work automatically via Autoscript

I got it working with this in Autoscript (note LD_LIBRARY_PATH.  This is needed to for sacd_extract to find libiconv.so.2).

CLI(CLI_exec cp /mnt/sd*/sacd_extract /3rd_data)
CLI(CLI_exec cp /mnt/sd*/libiconv.so.2 /3rd_data)
CLI(CLI_exec LD_LIBRARY_PATH=/3rd_data /3rd_data/sacd_extract -S &)

 

[Phthalocyanine]

3 hours ago, hyendaudio said:

I also noticed there is reference to a second folder called autoscriptSACD with the same set of 3 files,

I just tried to reply to you but I was blocked because I quoted some autoscript language to explain and the site thought I was trying to execute malicious code.

 

@mindset how did you indent quote your autoscript stuff to get around that?

[Phthalocyanine]

3 hours ago, hyendaudio said:

So what am I doing wrong?

To repeat what I tried to post but got blocked.

 

What I find odd is that you are not able to connect with telnet.

 

Look at the first two lines of the first script on page 6 of my guide.

 

Line one gets roots control and wipes out the existing password and creates the new password root.

 

Line two tells the player to launch the telnet daemon.

 

If those two commands are working you should be able to connect with telnet and use the new password root.

 

That’s not happening even thought your player seems to otherwise be responding to the scripts and I don’t know why.

 

Check the model number of your Pioneer.  It’s a 160?  Any other information on the back?

[mindset]

1 hour ago, Phthalocyanine said:

@mindset how did you indent quote your autoscript stuff to get around that?

I did nothing special.  I think it happened to trigger nothing.    Of course, I have seen the same problem with my older posts.

[hyendaudio]

15 hours ago, Phthalocyanine said:

To repeat what I tried to post but got blocked.

 

 

 

What I find odd is that you are not able to connect with telnet.

 

 

 

Look at the first two lines of the first script on page 6 of my guide.

 

 

 

Line one gets roots control and wipes out the existing password and creates the new password root.

 

 

 

Line two tells the player to launch the telnet daemon.

 

 

 

If those two commands are working you should be able to connect with telnet and use the new password root.

 

 

 

That’s not happening even thought your player seems to otherwise be responding to the scripts and I don’t know why.

 

 

 

Check the model number of your Pioneer.  It’s a 160?  Any other information on the back?

 

 

I saw those commands. Will check the detailed model # when I get home this evening.  Could the fact that the player was sourced 2nd hand from UK be introducing some strange behavior? 

[Phthalocyanine]

34 minutes ago, hyendaudio said:

Could the fact that the player was sourced 2nd hand from UK be introducing some strange behavior? 

I just don't know the Pioneer models well.  I've never even used one.  I know the Sonys.  So you may need the input from some other members on this one.  Once again, I find it puzzling that your Pioneer is obviously responding to the scripts (opening door, scrolling display) but you cannot get a telnet connection (which is the first step to get any real trouble-shooting going.)

[Knur]

Hello !

Thanks @Phthalocyanine for the libiconv.so. With it, the sacd_extract doesn't abort with the missing llibrary error anymore, but with the same error than the sacd_extract_160 : it seems the module is also incompatible...

@mindsetYou mentionned that you have a way to extract the kernel module from the sacd_extract binary, may you enlighten me ?

[Phthalocyanine]

2 minutes ago, Knur said:

With it, the sacd_extract doesn't abort with the missing llibrary error anymore, but with the same error than the sacd_extract_160 : it seems the module is also incompatible..

Did you follow @mindset technique of putting it in the same directory and using the autoscript from above

 

CLI(CLI_exec cp /mnt/sd*/sacd_extract /3rd_data)
CLI(CLI_exec cp /mnt/sd*/libiconv.so.2 /3rd_data)
CLI(CLI_exec LD_LIBRARY_PATH=/3rd_data /3rd_data/sacd_extract -S &)

[Knur]

I tested manually in a telnet session, I don't think doing it via the autoscript is gonna change something...

 

BUT it got me thinking... the order is important !

The player has to boot with tray empty.

Then the sacd_extract -S should be started, and only then a disk can be inserted.

 

Right now the sacd_extract is detecting the disc, the client is connecting... but the extraction doesn't start.

After a while the player reboot.

 

Is the trick about changing from M-Ch / Stereo somehow related to that ?

 

[Phthalocyanine]

10 minutes ago, Knur said:

Is the trick about changing from M-Ch / Stereo somehow related to that ?

Yes the timing of the toggle from M-Ch/Stereo is very important.  (Unless you are using the sleep-server method, which does not need the toggle.)

 

The main thing about the toggle is that it comes after you have loaded the disc.  (The point of the toggle is to release the player software's grip on the disc so that the ripper program can access it.)  Some people have run into trouble because they toggle before they put in the disc and it just will not work that way.

 

But all the scripts have to be in place and sacd_ripper has to be copied to player (along with any other helping libraries) before you load the disc.  Then you load the disc.  Then you toggle.  Then you execute your ripping command.

[hyendaudio]

4 hours ago, Phthalocyanine said:

I just don't know the Pioneer models well.  I've never even used one.  I know the Sonys.  So you may need the input from some other members on this one.  Once again, I find it puzzling that your Pioneer is obviously responding to the scripts (opening door, scrolling display) but you cannot get a telnet connection (which is the first step to get any real trouble-shooting going.)

 

I just checked, no unique model designation on the back, just the usual disclaimers and a sticker with s/n and mfr date (2013).

 

A regular old Pioneer BDP-160.

[MikeyFresh]

1 hour ago, hyendaudio said:

 

I just checked, no unique model designation on the back, just the usual disclaimers and a sticker with s/n and mfr date (2013).

 

A regular old Pioneer BDP-160.

 

Do you want to try the server method instead?

 

No reason why the local method and Telnet shouldn't work with that unit, but maybe you will have better luck with the server method as an alternative.

[Knur]

10 hours ago, Phthalocyanine said:

Yes the timing of the toggle from M-Ch/Stereo is very important.  (Unless you are using the sleep-server method, which does not need the toggle.)

 

The main thing about the toggle is that it comes after you have loaded the disc.  (The point of the toggle is to release the player software's grip on the disc so that the ripper program can access it.)  Some people have run into trouble because they toggle before they put in the disc and it just will not work that way.

 

But all the scripts have to be in place and sacd_ripper has to be copied to player (along with any other helping libraries) before you load the disc.  Then you load the disc.  Then you toggle.  Then you execute your ripping command.

 

Just a quick word before going to work, to let you know that it works !

Using the exact sequence you wrote above, I was able to rip a first SACD on my Sony S790. I used it in server mode with a sacd_extract client on my linux PC.

 

The 3 lines in the autoscript copying the file to /3rd_data don't work, though, I had to launch sacd_extract manually from a telnet session.

 

I'm curious about the "sleep-server" method, can you give me more info or point me to the post describing it ?

[Dick Darlington]

5 hours ago, Knur said:

 

Just a quick word before going to work, to let you know that it works !

 

👏👏 WELL DONE  @Phthalocyanine, @mindset, @MikeyFresh, @Knur and whomever I my have left out!

 

You guys are techno-Gods as far as I’m concerned!  🙌 🙌

 

It was quite interesting and enlightening watching this breakthrough playing out.

 

Have you considered contacting DC or Marvel about a possible film and graphic novel franchise?  I hear there is yuge money in action figures.  😅

[MikeyFresh]

1 hour ago, Dick Darlington said:

It was quite interesting and enlightening watching this breakthrough playing out.

 

I agree, though my part was tiny in wondering aloud about use of the Oppo script with the S790, which did not work but got the wheels spinning with the true experts.

 

I wish I had said something like that long ago, the first it crossed my mind was when very early in this thread a couple of members could not get the higher-end Pioneer LX58/88 to work, which now in retrospect seems likely to be a similar situation to this S790.

[Phthalocyanine]

2 hours ago, MikeyFresh said:

use of the Oppo script with the S790, which did not work

Well ultimately your idea worked!  It just needed an additional library (libiconv.so.2 )  to help it along.

 

2 hours ago, MikeyFresh said:

when very early in this thread a couple of members could not get the higher-end Pioneer LX58/88 to work, which now in retrospect seems likely to be a similar situation to this S790

That may be why, at some early point in the thread, someone uploaded libiconv.so.2, which, the pack rat that I am, I downloaded and saved for a rainy day.  The people attempting to use sacd_extract_160 with the Pioneer LX58/88 may have been getting the same error message as @Knur got for the S790 about the missing libiconv.so library.

 

So now Pioneer LX58/88 are back in the picture as possible SACD ripping decks.

 

Anybody out there got one to experiment with?

[MikeyFresh]

10 hours ago, Knur said:

I'm curious about the "sleep-server" method, can you give me more info or point me to the post describing it ?

 

The steps are as follows, but first you must enter the Sony on-screen displayed settings and enable the Quick Start mode, then:

 

Step 1: Power on Sony S490

Step 2: Connect USB thumb drive/AutoScript runs/tray opens automatically/load SACD but don't close the tray

Step 3: Power down Sony S490/tray closes automatically/pause while player goes to sleep/display flashes OFF/AutoScript gains root access control/remove USB thumb drive

Step 4: Execute/Run the rip in either SACDExtractGUI, or ISO2DSD

[Phthalocyanine]

29 minutes ago, MikeyFresh said:

you must enter the Sony on-screen displayed settings and enable the Quick Start mode

@Knur Here are some general things to keep in mind when you use quick start/sleep server mode.

 

In quick start/sleep server mode, the Sony still has its basic operating system running (the mediatek version of linux) and its networking ports are operating.

 

But the USB ports are disabled.  So sacd_extract has to be copied to root (as the default scripts do anyway) for things to work.  More specifically, you cannot use the telnet/local ripping method described in my guide in sleep server mode because the telnet/local ripper method depends on running sacd_extract from the USB stick (which cannot be accessed in quick start/sleep server mode).

 

You don't need the music setting toggle in sleep-server mode because the Sony player software, which, in wake mode, auto loads and mounts the SACD disc, is not operating in sleep mode.  No need to break the grip of the Sony sutomount with the toggle because the disc has not been automounted in sleep mode.  (And you couldn't do the toggle in sleep mode even if you wanted to because you cannot access the player menus in sleep mode.  You would have to turn the player on again and then you would be out of sleep mode.)

 

Sleep server mode is thus a combination of the traditional server methods using SACDExtractGUI, or ISO2DSD combined with the unique features of Sony players to be put in a sleep mode in which they none the less can execute network ripping.  (Hats off once again to @mindset for discovering this!)

 

One complication worth mentioning is that when the player is in sleep mode, every time you re-insert the USB stick into the player, the player gives the mounted USB stick a new designation in the Linux operating system - sda1 to sdb1 to sdc1 etc.  Now the stock scripts in the TSS folders designate sda1, so if the USB drive designation changes they will not work.  To get the USB drive back to sda1, you need to disable quick start mode, turn off the player (for real) and start all over.

 

Once you set up everything, you can run sleep mode "headlessly," that is with no monitor required.  All in all, a great method and one well worth perfecting if you're going to be going a lot of SACDs at once.

 

 

[Phthalocyanine]

10 hours ago, Knur said:

The 3 lines in the autoscript copying the file to /3rd_data don't work, though, I had to launch sacd_extract manually from a telnet session.

This raises a rather technical issue, on which @mindset might be able to enlighten us.

 

The folder  /mnt/3rd_data is the only non-volatile memory space in the Sony mediatek-linux file system.  So if you want to store a file on a Sony that will not disappear when you turn the player off, you need to store it there.

 

The stock scripts copy sacd_extract to root and run it from there.  But that will disappear in you turn off the player and you will need to re-insert the USB stick to get things working again.

 

For this new method for the S790 and S5200 to work, both the sacd_extract program and the libiconv library have to be in the same folder.  That folder can either be root or /mnt/3rd_data, but you have to chose one or the other and your scripts have to specify the correct folder.  @mindset had both in /mnt/3rd_data, so that's why his script uses it.  But you, using the stock script had sacd_extract copied to root, so mindset's script referencing libiconv in 3rd data would not work because that's a different directory than root and both have to be in the same directory.

 

Is that correct, @mindset?

[MikeyFresh]

39 minutes ago, Phthalocyanine said:

One complication worth mentioning is that when the player is in sleep mode, every time you re-insert the USB stick into the player, the player gives the mounted USB stick a new designation in the Linux operating system - sda1 to sdb1 to sdc1 etc.  Now the stock scripts in the TSS folders designate sda1, so if the USB drive designation changes they will not work.  To get the USB drive back to sda1, you need to disable quick start mode, turn off the player (for real) and start all over.

 

Great overall post as it details all of the differences and nuances between the local ripping process using Telnet and the sleep server method on a Sony.

 

The part I quoted above is crucial and was not necessarily properly detailed in many of my previous posts showing the sleep server steps, though @mindset did make mention of it at the outset.

 

I have since added the part about "remove USB thumb drive" to the steps, however that doesn't really explain it fully either, but @Phthalocyanine does describe it perfectly above and the take away is after you've removed the USB thumb drive, DO NOT reinsert it as that will only cause a bunch of problems. 

 

Once one rip has finished, simply eject the disc that was just ripped, place a new disc in the tray, and Power OFF again, at which point another rip can be Executed/Run in the GUI. You can repeat the above as many times in a row as you wish, and the AutoScript would only need to be reinserted if the AC power to the machine was physically cut.

 

My S590 is currently on a 7-8 week run of never having had the AutoScript read-in again, when I turn this unit OFF at the end of a rip session, it actually just sleeps due to that Quick Start setting. When I awaken it with Power ON (or even Open/Close), it is all set to rip, the AutoScript is still there from the previous session, I load a disc and Power OFF, then rip all over agin, repeatedly, for weeks on end.

 

39 minutes ago, Phthalocyanine said:

To get the USB drive back to sda1, you need to disable quick start mode, turn off the player (for real) and start all over.

 

I'm pretty sure you can skip the disabling of Quick Start mode in order to reset this process, I don't remember for sure anymore but I believe just a complete power cycle (pull then replace the AC plug) will suffice.

 

Another thing I've noted as different with these Sonys as compared to the Oppo or Pioneer is that with at least some models and firmwares, the Sonys do not like being booted up with the AutoScript thumb drive already inserted, which is unlike the Oppo and Pioneer which seem not to care about that.

 

But on at least some of the Sony units I have (possibly firmware specific), they act wonky when the unit is booted up with the thumb drive already in place, it's best to let the unit's initial boot sequence take place with the AutoScript removed, which again, is unlike the Oppo and Pioneer that don't seem to care about that at all.

 

[hyendaudio]

21 hours ago, MikeyFresh said:

 

Do you want to try the server method instead?

 

No reason why the local method and Telnet shouldn't work with that unit, but maybe you will have better luck with the server method as an alternative.

Hi MikeyFresh.

 

I just replied to your PM as well. I've gone to the DropBox link you provided (re-publishing here for anyone else who's interested, as I had to search a bit to find one the first time - BDP-160 AutoScript) and I still get the same result. The player boots fine off the USB drive and the door opens. I load a CD and the player reads it, properly identifying it as an SACD. I then ran Sonore's iso2dsd application (I'm guessing that's what you mean by "server method"), correctly entering the pingable IP address (192.168.0.160) with the default port of 2002 and the result is: Failed to connect libsacdread: Can't open 192.168.0.160:2002 for reading. 

 

Thank you again. 

 

Should I throw in the towel on this player and go for a Sony? I'm reluctant to try an Oppo as according to what I've read, if the firmware's been updated it won't work.

[Phthalocyanine]

28 minutes ago, hyendaudio said:

I'm reluctant to try an Oppo as according to what I've read, if the firmware's been updated it won't work.

I've never heard that.  As far as I know the 103 and 105 work for SACD ripping with all known firmware.

 

Some people blink at the cost of these units.  But if you wanted to invest in a quality BD player anyway, they're wonderful.

 

If you just want a SACD ripping machine, the you can't go wrong with the Sonys.

[MikeyFresh]

41 minutes ago, hyendaudio said:

've gone to the DropBox link you provided (re-publishing here for anyone else who's interested, as I had to search a bit to find one the first time - BDP-160 AutoScript) and I still get the same result.

 

OK the first thing I'd like to point out is that the link above appears at least twice in the very early pages of this thread.

 

I don't host that link or I'd change it for one simple reason, MANY people have had trouble with it because it does not point to an Enclosing folder called AutoScript, it points to that folder's contents. SO many people have just downloaded the contents, and they lack the enclosing folder that is necessary, so for full clarity, in the Drop Box GUI, you use the Download button found at the upper right-hand side and that does download the entire enclosing folder called AutoScript:

 

 

Then, resist the temptation to try opening that very first item within the folder called AutoScript, because if you do it will likely then have a .txt file extension, which breaks it. Worse yet, one wrong keystroke inside that file and it is broken. So don't click into it and if you did but are sure no stray keystrokes were made, also then ensure any .txt file extension/association is deleted.