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

[Phthalocyanine]

To the person with the Pio 150 -- don't give up without trying a few things.

If the telnet script is working (the "abcdefg" stuff) then follow the directions in post #71.

At the least, see if you can telnet in and use the command uname -a to see what kernel of Linux it is running.

[Phthalocyanine]

To iwf

Recheck the basics.

Check that you're using the correct IP address, although, if you're pinging it, it sounds like you have that correct.

What happens when you try to make a telnet connection with "telnet 192.168.etc"

Connection refused?

Try a new or fresh USB stick with the folders. We have had many cases of people using models such as the Oppo ones that we know will work who didn't get it to work until they tried different USB sticks.

Finally, check out the instructions of this Japanese blogger who is using a slightly different script.

Here's the link which goes to Google translate. (If not, run it through Google translate.)

https://translate.google.com/translate?hl=en&sl=ja&u=http://mimizukobo.sakura.ne.jp/articles/articles018.html&prev=search

 

Here's the relevant part translated:

 

[h=1]SACD ripping Act 2 Act (2)[/h][h=3]How to telnet[/h]It is an introduction on how to invade BDP (Blu-ray Disc player) using the highlight of the second act, telnet. It is the same way that sneaks into the impregnable "Navaroon's fortress", sets a bomb on the elevator, causing great confusion.

 

The telnet method with BDP-170 has detailed commentary on # 71 there is another for the manual telnet sacd_extraction . You ought to do so. The first part of the message explains the difference between oppo script and Toshiba script. The second part is telnet commentary.

For ripping method using telnet # 695 Telnetting into and issuing "sacd_extract - I" rips directly to the connected disc is introduced . After logging in with telnet, you should enter AutoScript and execute sacd_extract.

 

Here I will show you how I tried. Because it is different environment, it is somewhat different from # 695. I think that this one is a bit simpler than # 71.

Turn on the BDP - 170 and set the SACD.

 

Edit a text file with the following contents with notepad.

# MTKAT 0.xx script CLI (CLI_exec / usr / sbin / inetd &) SLEEPMS (3000) CLI (CLI_exec echo root :: 0: 0: root ,,,: / root: / bin / sh> / etc / passwd) CLI (CLI_app.vfdmg.b clear_msg) CLI (CLI_app.vfdmg.b scroll_msg start) SLEEPMS (5000) Place the text file as a script named AutoScript and AutoScript.TSS in a directory named AutoScript and save it in the root of the USB memory.

Extract the archive from Maldur's dropbox described last time and retrieve the AutoScript directory. Change the name to AutoScriptSACD. Save AutoScriptSACD in the root of the USB memory.

170 is plugging in the USB for telnet with the power on.

When "ABCDERG ..." is displayed on the panel, telnet is started with putty.

Linux 2.6.35 (192.168.0.9) (pts / 0) Mtk8530 login: root - sh - 3.2 # ls / mnt / sda 1 / AutoScript AutoScript SACD BUDA System Volume Information -sh-3.2 # cd / mnt / sda 1 / AutoScriptSACD / -sh-3.2 # ./sacd_extract_ 160 - I [0]: convert_string (): Conversion not supported. Charsets: ISO646 - JP -> UTF - 8 Processing [bPHR STEREO SOUND SAMPLER (1) .iso] (1/1) .. · · · Completed: 1% (47.0 MB), Total: 1% (3272.1 MB) at 2.24 MB / secLs / mnt / sda 1 / is for checking the directory contents. It is possible to ripping by inserting the memory, launching telnet, moving the directory, and executing sacd_extract_ 160.

The advantage of this method is that if you have a high-speed USB connected hard disk, you can quickly and efficiently ripping (also written in # 695). Since data can be transferred directly internally, it can be processed at the highest speed.

 

As for telnet, tmtomh went to # 120 Is it true far that far far from the Oppo (and now Cambridge) units refuse the telnet connection, while the Pioneer 160/170 accepts it? Not an issue for SACD ripping, but just curious ... Ted_b has revealed that telnet and ripping are irrelevant ( # 126 This is all great feedback ... that the most foreign of steps (telnet) is now an option worth Skipping .

An opening message is written in this unclear situation, so be careful.

[Phthalocyanine]

P.S. The standard telnet port number is 23 not 37.

[Phthalocyanine]

MikeyFresh,

Your player is just playing the disc when it is ripping it. Even a cheaper drive is designed to play back discs a thousand times. But I'm sure the Cambridge CXU is a fine player.

[Phthalocyanine]

To haggis99

The Telnet method uses a different script and, as far as I remember, only works with the Pioneer, not with the Oppo.

(And one telnets to a different port than port 2002 in any event.)

So I wouldn't get sidetracked with trying to telnet.  Pinging is sufficient to see whether you have a network connection to your player.

[Phthalocyanine]

To Matt,

I see what you are saying but this is what I do not understand,

As far as I know, the telnet function of an Oppo or a Pioneer is not normally running.

You need a script to gain root access to turn on the telnet genie and change the password to something known.

So one needs to run one of the scripts to get telnet access.

And as far as I know no one has gotten telnet access to the Oppo (as opposed to the Pioneer).

[Phthalocyanine]

If one tries to connect via Telnet to a Pioneer without the script running, the response will be "access denied."

To the extent you get this response, as opposed to "unable to reach 192.168. etc," then you have I suppose verified that you at least have a network connection to the right IP address.  But I don't know if this adds anything more than a Ping test.

[Phthalocyanine]

So the scenarios are

 

(1) a successful telnet connection (requires root access through a script).  Indicates a successful network connection to the player too of course.

 

mudkip@mudkip:~$ telnet 192.168.1.139
Trying 192.168.1.139...
Connected to 192.168.1.139.
Escape character is '^]'.

 

(2) A failed telnet connection attempt that at least shows you're using the right IP address and thus indicates a network connection to the player

 

mudkip@mudkip:~$ telnet 192.168.1.139
Trying 192.168.1.139...
Access denied

 

(3) A failed telnet connection where you do not even have the right IP address and thus indicates you do not even have a network connection to the player

 

mudkip@mudkip:~$ telnet 192.168.1.139
Trying 192.168.1.139...
Unable to connect to 192.168.1.139...

 

Note that in most telnet terminal programs (here Linux) you do not indicate the port.  The telnet command uses the default port.   Port 2002 is not a telnet port and cannot be checked this way.  2002 is a port the SACD ripper program uses and the SACD ripper program has to run successfully to open it up.)

 

So haggis999, the best you can hope for is scenario 2.  And if you get scenario 3, then you need to troubleshoot the IP address for your player or other basic network connection issues.

 

 

 

[Phthalocyanine]

I rip "locally," that is directly to a USB drive connected to the player.  (This is possible with a Pioneer using a Telnet connection and is documented earlier in this thread.)  This removes any network lag from the ripping process, but my rip rates are still around those discussed above -- 2 - 3 mbps, around 20 - 30 minutes per disc depending on the size of the SACD.  The rip process itself is about 4x at most and this cannot be sped up.  So while it is always useful to try to speed up your network connections, you may not see great results here because of the nature of the SACD ripping process.

[Phthalocyanine]

Or format the USB drive in NTFS if your player can read that.

[Phthalocyanine]

According to its spec sheet, the Pioneer 160 reads NTFS from USB. It should be able to write to it via the ripping program if he rips locally.

[Phthalocyanine]

ExFat may well be the wave of the future for high-capacity USB storage, but the only relevant issue for LeonJehae is what formats his Pioneer 160 will recognize in USB.  NTFS is listed in the specs, ExFat is not.  I'm sure some Pioneer 160 owners can chime in on whether or not ExFat will work for the Pio 160.

[Phthalocyanine]

The question is whether one can rip locally (that is to an attached USB thumbdrive or harddrive) using the new method with Oppos and Pioneers.  The answer is Yes.  Several posters here have done so.  Search for posts by "Roberto."  This can be a good method for those with a slow network connection to their player. 

 

However, looking back on the post by LeonJehae, it is not clear that that was what he was doing.  It seems like he was ripping to his computer through the network but was worried about the FAT32 4GB file size limit on his computer.  But no major computer operating system has used FAT32 as their file system since Windows 98.  So I think he never had a problem to begin with.

[Phthalocyanine]

Quote

 I think FAT32 is still around and still supported in Windows because of its compatibility with other OS's

 

Yes, of course, FAT32 is still supported in Windows, in the sense that a computer running Windows can read this file system.  Windows can read a number of different file systems (like UDF on DVDs etc.)

 

My only point was that Windows currently uses NTFS as the file system for its operating system (and has since at least Windows XP) and consequently there is no file size limitation issue when copying large files to a Windows computer via network, which I think was what LeonJehae was worried about.

[Phthalocyanine]

The BUDA folder is created by the BD player to store BD-Live content.

It is unrelated to the ripper program.

[Phthalocyanine]

@frfrtx

In order to create a SACD-R from ripped .dsf files you would need, in effect, a SACD authoring program.

Such a program exists somewhere for professional use, but I have never seen it available generally.

Sony actually created a simple format for a "DSD disc" by which you can author it with .dsf files.

The problem is that DSD discs are only read by the PS3 and a few other Sony players the SCD-XA5400ES  and  the SCD-XE800.

I made one for kicks and played it on my PS3 but the format is otherwise pretty useless.

This is why everyone recommends ripping to .iso and saving that before extracting .dsf files.

You'll have to go back and rip the .isos on those SACD discs if you only have the .dsf files.

 

[Phthalocyanine]

@ tdacquisto

 

What's the rest of the equipment in your audio rack and what make are those good-looking stand-mount speakers?

[Phthalocyanine]

Any region-free modification has no effect on the exploit being used here, which concerns the most basic structure of the player, as many previous posts have confirmed.

 

As mentioned in a post long ago (back when they had numbers, it was 71) there are at least three different Autoscript folders and one should be used for the Oppo and the others for the Pioneer.  The Oppo does not use the Telnet one.

 

#71

 

Yes, as I mentioned earlier, there are customizations out there. So here goes: There are at least three different Autoscripts:
* the one I originally linked (and seems to be working fine for some CA Oppo users, for example) is the one for automatic sacd_extract execution. It's contents looks like this:
#MTKAT 0.xx script

CLI(CLI_exec cp /mnt/sda1/AutoScript/sacd_extract /)
CLI(CLI_exec /sacd_extract -S &)
CLI(CLI_drv.ir.rx.sq 0xaf000)

* below is a similar Autoscript with extra buffering for the BDP-160 (see my dropbox link below or Maldur's post and follow instructions)

#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)

* there is another for the manual telnet sacd_extraction and requires command line execution, but allows one to watch via telnet, and add buffering manually. It's content looks like this:
#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)

 

[Phthalocyanine]

I have discovered a new model that can be used for SACD ripping with the exploit discussed in this thread:

Sony BDP-S590

This is the midrange Sony Blu Ray player from 2012, which like all Sony’s Blu Ray players from that year, plays SACD.  I have reason to believe, but have not personally confirmed, that the exploit would work for all the Sony Blu Ray players for that year 2012.  I include a list of suspected models below.

The methods for using the exploit is exactly the same as that used for the Pioneer 160 with the following additional work-around:

The workaround is that after loading the disc, and right before one hits the button to start the ripping, one goes to the music settings and changes one of either two settings for SACD discs ([1]SACD or CD layer or [2] stereo or multichannel).  I usually use the stereo or multichannel setting.  As far as the ripping goes, it does not matter which one you set it to, as long as make the change just before starting the ripping.  If the setting is currently set to stereo, change it to multichannel.  If the setting is currently set to multichannel, set it to stereo. It is the changing the setting that is important for the reasons discussed below, not the setting itself.  Whatever the setting was when you loaded it, change it to the other one before you rip it.  The setting change is not instantly applied to the disc.  You would have to reload the disc for the new settings to be applied.  It does not matter whether stereo or multichannel is selected because ripping the .iso rips the whole disc image and all the contents of the disc.

I hypothesize that the reason one has to change one of these settings to get the ripping to work on the Sony is the following:  The Sony player, unlike the Oppos or Pioneers that are described in this forum thread, does not have any obvious setting to turn off autoload the disc.  The Sony automatically autoloads the SACD when you put it in.  But when a disc is autoloaded, this prevents the SACD ripper program from accessing the disc and it won't work.  But merely changing either music setting described above breaks the autoload so that the ripping can happen.

So for the S590 use the Autoscript, Autoscript.TSS, and sacd_extract etc. as described for the Pioneer 160.  You can use the telnet method with the S590, and that is primarily how I have used it.  I have ripped locally to a USB drive.  If you do this you can format the USB drive to NTFS (rather than FAT32) and rip .iso images larger than 4GB (another nice feature of the S590. which people who did their ripping with the PS3 and had the 4GB limit will appreciate.)

But the “server” method works fine with the S590, and that is the technique described in most of the guides here.

Because people sometimes have had problems with particular USB sticks, I will list two brands that I have personally used successfully for the ripping process with the S590:

SanDisk Cruzer Glide USB 2.0 32 GB

SanDisk Ultra USB 3.0 128 GB

I suspect but cannot personally confirm that the following Sony Blu Ray players from 2012 will also be subject to the exploit, since I believe they are all based on the same mediatek chipset:

BDP-S390

BDP-S490

BDP-S790

BD Home Theater/Home Cinema Systems from 2012 with SACD:

    BDV-E190

    BDV-E290

    BDV-E390

    BDV-E690

    BDV-N590

    BDV-N790W

    BDV-N890W

    BDV-N990W

I can personally confirm that the Sony BDP-S185 (from late 2011) has the same chipset as the 2012 line and is also subject to the exploit.  Unfortunately this model does not read SACD and therefore will not work for SACD ripping.  (At least I cannot get it to work.)

I have tried using the exploit for some Sony Blu Ray players with SACD from 2010 (the BDP-S370, S570, etc.) and 2011 (the BDP S380, S580, etc) but it does not appear to work for these. (At least I cannot get them to work.)

I have not had the opportunity to try the exploit with Sony Blu Ray players from 2013 that read SACD, such as

BDP-S5100

BDP-S4100

Home Theatre:

BDV-N9100W

BDV-N7100W

Maybe someone out there with one of these can try it out.

[Phthalocyanine]

Yes, the Sony BDP-S590 was a mass-market model sold at Costco or Walmart and there are plenty floating around, which is how I ended up picking up two of them at thrift stores.

For those who buy one -- don’t upgrade the firmware.  This is not because that will prevent use of the exploit.  It will not.  Rather it is because up through firmware M12.R.0430, the BDP-S590 will play SACD-R discs (SACD .iso images burned on DVD).  This is a nice feature which Sony disabled in later firmware.  Actually, it is possible to downgrade the firmware of this model and some other Sony BD players thanks to the work of this developer here:  http://www.malcolmstagg.com/bdp-s390-downgrade.html

I’ve successfully done that with my two BDP-S590s.  But try the SACD ripping exploit first without worrying about downgrading, because downgrading is its own somewhat complicated process.

I went down this path based on an exchange much earlier in this thread.  Someone else was experimenting with a BDP-S590  (The post and page numbers are from when this thread had them under the old server):

Post 795 (page 33):

Appreciate the info so far! Of course I had to try my SONY BDP-S590 just for the heck of it...the Autoscript works at least, as does the script with the TELNETD setting. Got this on the telnet uname -a:

Linux sony-player 2.6.35 #1 PREEMPT Wed Jul 11 19:37:04 JST 2012 armv6l GNU/Linux

So strikes one/two/three, right off the bat. And when I try to run the EXE, it crashes on my Win10 device. Oh well.

*

Originally Posted by mocenigo

Could you rip in the meantime? (Maybe copying locally to removable media?)
*
That's a good point - I'll try that tomorrow. I assumed the crash meant that the app simply wasn't supported but it's worth a shot to try and run the tool via telnet.

*

Nah, didn't work. Needed the libiconv.so.2 first off (grabbed that from one of the earlier posts). Ran the binary via telnet, got this:

/mnt/sda1/AutoScript # ./sacd_extract -I
insmod: can't insert '/tmp/filevKgrMe': invalid module format
[0]: install_modules: mknod/insmod filed
rmmod: can't unload 'sacd_read': unknown symbol in module, or unknown parameter
[0]: Can not install modules

Again, my assumption here is that it's the wrong chipset, where the tool simply doesn't work. Worth an attempt however.

*

I am not sure the chipset makes per se ripping impossible. This seems just that the tools are. It compiled for the target platform. You can get inside, as root, and thus have access to the SACD device. Ripping should be possible - but the Pioneer and OPPO tools may not be able to run unchanged.

*

Try different sacd_extract daemon from Maldur's post
And don't forget to reboot blu-ray player after any unsuccessful attempt

***

Me, Phthalocyanine, speaking again:

The reference to the Muldur post is the set of tools for the Pioneer 160, which is what I have used successfully.  (I never had to do anything the libiconv.so.2 file mentioned in the exchange.)

The original poster on the S590 was getting the error message

insmod: can't insert '/tmp/filevKgrMe': invalid module format
[0]: install_modules: mknod/insmod filed
rmmod: can't unload 'sacd_read': unknown symbol in module, or unknown parameter
[0]: Can not install modules

because the S590 had automounted the SACD disc and there is no setting on the S590 (unlike the Oppo and Pioneer) to stop automounting. 

(It turns out that the S590 will not automount SACD-Rs and that was how I first got any ripping to work before I discovered the work-around.  Of course ripping SACD-R discs is fairly pointless, but it steered me in the right direction.)

When I discovered the work-around that temporarily unmounted the SACD disc (the changing the current setting in either of the two settings in music), I could rip.

[Phthalocyanine]

@billbillw

Very interesting observation on the BDP-S790.

If you can find the service manual for the Sony BDP-S185 could you check that one for the part too?  As I mentioned in my initial post, I own a Sony BDP-S185 and can personally attest that the exploit works on that model too (I can telnet in and have root control). It doesn’t work for SACD ripping because this model is not SACD capable.  It would be interesting to see what the correlations are between part number and the mediatek chipset and exploit vulnerability in the various Sony models.

[Phthalocyanine]

@ted_b

As I said in my initial thread, the one model I can personally confirm will work for SACD ripping is the BDP-S590 and I explained precisely how to do it with the work-around described.

The information on other models is useful for further discoveries that might lead to more SACD ripping with further Sony models.

 

[Phthalocyanine]

@billbillw

I have the service manuals and it looks like the IC101 in the BDP-185 is part CXD90007G-AA.  The IC101 for the BDP-S590 is variously listed as CXD90007G-AA and CXD90008G-AA.  So it looks like you're on to something.

[Phthalocyanine]

Additional information for those looking for a Sony BDP-S590

The model was also marketed in the United States as the Sony BX59.

Internationally, the same model (but without WiFi) was marketed as the BDP-S490.

[Phthalocyanine]

@ [email protected]

The Sony BDP-S485 is a model I did not previously know about.

From its service manual, it’s a Sony Blu-Ray player model with SACD and Karaoke from 2011-2012 marketed in China, Singapore, Thailand, and Russia,

The question is whether it has the chipset of the S590 family from 2012 or the S580 family from 2011.  I could not get a S580 to work for ripping.  So if the S585 is like the S580 it will not work.

It is certainly worth trying however because the S485 has SACD capability and is close to the right time range.

The lack of the front tray opening is not necessary a sign that it will not work.

There are different versions of the exploit and not all of them open the front tray.

I have been using the telnet method for the Pioneer 160 and that version does not open the tray.

The telnet method is best for figuring out exactly what is going on because you get actual feedback from the player as you issue the commands.

The telnet method is described early on in this thread.  I or a colleague are planning to post our detailed guide to using the telnet method with the S590 soon.

(To be clear, the S590 also works with the “server” method in combination with iso2DSD.  It is just that I haven’t personally used that method in long time, since I prefer the telnet method.)