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

[mutant_matt]

(sorry the post got so long... )

 

I am hoping someone has some ideas that could get me further. I have a Cambridge Audio 751BD based on the MTK8530. I know that this is not supported, but, I am having a go anyway, as there are possibly promising signs, if I could just make a bit more progress. I am very computer literate (as it's what I do) and networks also. I am running Linux, and can happily come up with alternative solutions to most Windows/Mac instructions and tools everyone has been talking about in this thread (including using Wine and Virtualbox, when I absolutely have to run a win32 (or x64) binary). I have read the whole thread (finally), and have got this far:

 

1. I have created multiple USB sticks of various sizes (all < 32GB), all FAT32, all with an MBR and the BOOT flag set. All of the sticks I've used are recognised by the 751BD and all of them execute the script in the AutoScript folder on the sticks.

 

2. My 751BD is using a static address on the (wired) network, on the same segment as my (wired) desktop pc, and from the pc (running Linux), I can ping the 751BD when it is on, and if I turn on "My Network" on the 751BD, I can see that the 751 is then listening on TCP port 48360. I mention this to prove that I have connectivity and know how to use ping, nmap and netcat (nc). There are no Firewalls or anything getting "in the way" of the pc connecting to the 751, is my main point, and I know how to diagnose this if it were to be happening (which it is not).

 

3. I have tried various incantations of the AutoScript files with the following results:

 

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

 

The drawer opens once the USB stick is in, and recognises the SACD in the drive, but as AutoPlay/Resume are turned off, does nothing further. The 751 does not listen on port 2002 as it should when the sacd_extract binary is running on the 751 proven using nmap and nc (the 751 is pingable the whole time).

 

The same above is true if I use the "160" (i.e alternative) version of sacd_extract.

 

The sacd_extract binary must be the thing opening the draw, as without this command in the script, it does not open the draw. That means that the binary must be to some degree compatible with the environment, or else it wouldn't run at all (I realise opening of the draw using this binary does not indicate further success! )

 

If I test the script to prove it's running another way, I have tried just doing the front display test:

 

#MTKAT 0.xx script

 

CLI(CLI_app.vfdmg.b clear_msg)

CLI(CLI_app.vfdmg.b scroll_msg start)

SLEEPMS(5000)

 

This works fine, but of course, does nothing but displays the ABCDEFGHIKJ on the front display of the 751. If I then try:

 

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

 

it doesn't seem to start the telnet deamon, but does still do the ABCD... scrolly display (using telnet, namp and nc, it's not listening on the telnet port (23) or any other port (if I do a full-range port scan)). I have also tried starting inetd as well, as I found some instructions on another site which use that binary instead.

 

It must be correctly mounting /dev/sda1 as it's running sacd_extract, which it copies to / (root) to run, but, I have also tried doing some diags, and didn't get any files written to the USB stick:

 

#MTKAT 0.xx script

 

CLI(CLI_exec echo root::0:0:root,,,:/root:/bin/sh >/etc/passwd)

CLI(CLI_exec cp /etc/passwd /mnt/sda1/AutoScript/)

CLI(CLI_exec ls -lR / > /mnt/sda1/AutoScript/files.txt)

SLEEPMS(3000)

CLI(CLI_app.vfdmg.b clear_msg)

CLI(CLI_app.vfdmg.b scroll_msg start)

SLEEPMS(5000)

 

I wonder if the 751 is missing some of the BusyBox binaries in /usr/sbin as when doing the "telnet debug thing", that should just invoke the telnet deamon already installed on the 751 from /usr/sbin, unless, of course, for some strange reason it's not there (which seems unlikely). I also can't understand why at least the cp command doesn't work (unless the 751 opens the USB stick read-only (which is possible)).

 

If I could just get telnet working, I might be able to get further.

 

I only actually have one SACD left that I haven't replaced in other ways, as it's the 5.1 multichannel off of Dire Straits, Brothers In Arms that you can't seem to get by any other method (legal or otherwise). I generally buy BD Audio discs, not SACDs, so this is the only disc left that I REALLY need to get backed up. Also, it's very annoying as this is the only single physical disc left out of the thousands that I own, that I actually have to put in the player, everything else in my collection is accessed via Kodi in my lounge connected to my 5.1 Home Cinema system.

 

Any help/suggestions, greatly appreciated,

 

Cheers,

 

Matt.

 

P.S. Kal (if you're reading this), isn't your multi-input DAC product wish, just a very extensively spec'd high quality AVR with some extra stuff added on? Some of the better pre-pros might seem to support most of your wishlist?

[mutant_matt]

Sure, I get that. However, I'm technically curious, and it feels like I *should* at least be able to get telnet going with a bit of digging/effort... (and with telnet, I can really figure out what should/should not probably be possible...)

 

Actually, if you're feeling generous, would you be up for running a few commands via telnet on yours for me and sending me the results?

Cheers,

Matt

[mutant_matt]

Matt, I commend you for all your investigations. It looks like you've narrowed down the problem - the 751 isn't initiating telnet/listening the way it would need to in order to make SACD ripping work. Ted might be right that it's a dead end, but in any event it seems like the only possible path to a solution would be communicating directly with the folks who wrote the initial script and putting your collective heads together.

 

I certainly lack the knowledge you and they have, but it seems to me, at least in principle, that it should be possible to add more chipsets to the compatibility list by modifying the script - or to more definitively rule out other chipsets by investigating further to determine once and for all if and why those chipsets/implementations can't be supported by this type of script at all.

Indeed. To my mind, there are two parts to this. 1) getting telnet working 2) getting the correct binary to match the chipset/environment to enable actual ripping.

 

Right now, I'm just trying to achieve 1). As the cp (copy) command seems to be working off the USB stick, as sacd_extract seems to be executing (it's opening the draw), then if cp is working, then I would expect most of the standard BusyBox commands and utilities to work (which is why I feel frustratingly close to getting telnet working!) ). If I could get telnet working then I can have a proper poke around the file system... Having said that, cp is an "internal" program "inside" BusyBox, if I understand BusyBox properly, but telnet is an external binary (looks like it lives in /usr/sbin), which may or may not exist on the 751 (it does on the supported players).

 

I think it may be a whole another matter to get sacd_extract working for other chipsets, as that will most likely require modifed code and re-compilation for the chipset in question, which is another level of work! (but one step at a time )

 

If someone was willing to run a few telnet commands on their unit for me, I might be able to figure it out...

 

Cheers,

 

Matt

[mutant_matt]

Actually, it is the other way around. What I want is a high end prepro with many things left out. ;-)

 

Heh. Are we talking Emotiva/Classe "high end" or (wishful) higher? (I run a Cambridge Audio 751R with the amps switched off because it's the closest thing that I can find, within my (current) budget, that acts as a decent pre-pro and by default is setup to do not much to the signal and has the inputs I need, has the decoding I need, and the multi-channel outs that I need, and doing just this job, sounds way above it's price point! (especially the price I paid for it!))

 

, Matt, can I ask you where you are based (country)?

South East England (UK)

 

Cheers.

[mutant_matt]

While I could get the file to load off the USB and have the drawer pop open, I could neither connect to the machine via Telnet (connection refused error) or to have SACD Extract work (it crashes on Win10 within a few seconds of running the CMD file).

If the Bluray player isn't listening on port 2002 (which seems to be hard coded into the sacd_extract binary that runs off the USB stick when plugged into the player), then when you run the sacd_extract.exe binary on Windows, it crashes when it can't establish a connection (TCP network connection from your pc to port 2002 on the player). The Bluray player won't be listening on that port if the binary on the USB stick doesn't match the correct chipset in the player (i.e. you're not using a supported player, of which the list is quite short...). You can get close, and it looks like it should work, on similar but not known to be supported chipsets, like I did with my CA 751BD (MTK8530), where the binary runs and opens the drawer, and will update the front display, but never actually sets up the network port to listen on port 2002 (so ripping can never take place). HTH!

[mutant_matt]

So, do I just connect OPPO and MacBookPro with a network cable and that's it, no switch, no router? Do I use a normal network cable or the crossover one?

Depends. A "normal" (straight through) network cable from one device directly to another will work if both ethernet ports are gigabit capable ones (MacBookPro should be, I have no idea about the Oppo). It's easier and more straight forward to use either a crossover cable (if you have one) to guarantee it to work, or use a normal network cable connected to a router or switch. I'd recommend the router method, as that is likely to sort out the DHCP IP addressing for you on both machines as well, which leaves you just to discover the IP address the Oppo has been given. Make sure you can ping the Oppo from the Mac before you start and you can use this telenet command to test if the Oppo is listening in port 2002, once you've put a disc in the tray: telnet 2002 If it's not listening, the extraction won't work; either you get sacd_extract.exe crashing in Windows, or the extraction method you're using reports: libsacdread: can't open :2002 for reading If it's not listening on port 2002, you can always try the telnet into the Oppo method, and attempt to run the extraction manually via telnet, but that is more involved. HTH! Cheers, Matt

[mutant_matt]

I have ripped my first SACD to an ISO file. I have now found out you can use ISO2DSD to convert the file to DSF. Is the SONYDSF the right choice? I have read about the PhillipsDSDIFF and DSDIFF, but am still not sure if the SonyDSF is the right one to use. Thanks for any clarification.

I'm not sure that there is a "right" choice, to be honest. I think a lot of it depends on what you want tagging wise, and what you're going to do with the files for playback (i.e. what device will support what format and if/how you want metadata displayed). Some people also have a preference for file format from a decoding/sound quality point of view. You can also, by the way, use the sacd_extract.exe program to convert the .iso file into DFF/DSF files, the same as ISO2DSD. I run Linux so use wine to run the .exe to extract the tracks to .DSF files, and then use the excellent DSD2FLAC to convert the DSF to 88.2/24 Flac files (2.0 and 5.1) as I use Kodi via HDMI to a PCM only decoder (with Kodi nor my decoder handle DFF/DSF well (or at all)). I think I could easily also use ISO2DSD though (but as I run a 32bit Linux I can run sacd_extract.exe with wine natively, I have to fire up a Linux 64bit Virtual Machine to run DSD2FLAC). I also use the -P option of sacd_extract.exe to write the iso disc metadata out to a text file to keep with the ripped files, as that has useful title, date, production, catalogue and track data I thought would be handy to keep. HTH! Cheers, Matt

[mutant_matt]

Make sure you can ping the Oppo from the Mac before you start and you can use this telenet command to test if the Oppo is listening in port 2002, once you've put a disc in the tray: telnet 2002 If it's not listening, the extraction won't work; either you get sacd_extract.exe crashing in Windows, or the extraction method you're using reports: libsacdread: can't open :2002 for reading If it's not listening on port 2002, you can always try the telnet into the Oppo method, and attempt to run the extraction manually via telnet, but that is more involved. HTH! Cheers, Matt

I just realised that the formatting I used caused this post to not make sense and I couldn't figure out how to edit, so am quoting myself. It should read: "once you've put a disc in the tray, type in a command prompt (windows/cmd, Linux/Mac/shell): telnet 192.168.123.1 2002 (where 192.168.123.1 is your IP address of your Oppo)" Hope that clarifies, Cheers, Matt.

[mutant_matt]

Are there any switches in the ISO2DSF configuration to preserve a single quote in the song file name. I have to go and back re-edit my files names or regenerate them again against the metadata. For example the song "I've been waiting for You" gets generated as "I Ve Been Waiting For You"

I can't help with ISO2DSF, but, give it a try using sacd_extract.exe? I suspect this *may* be related to which operating system you are using (Windows?), rather than the tool, but try sacd_extract.exe because that's what I use to create the DSF files from the ISO, but running on Linux (running the .exe using Wine). I have not had this problem (example, Deep Purple, Machine Head, Maybe I'm A Leo). The command is: sacd_extract -i filename.iso -s -2/-m (for stereo/multichannel extraction). sacd_extract -? for the options. HTH! Cheers, Matt

[mutant_matt]

22 minutes ago, haggis999 said:

Every time I try to rip an SACD loaded in my Oppo BDP105EU, I now get the following error.

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

 

Deleting and reinstalling the program has made no difference. Does anyone have any suggestions for fixing this?

 

That's the error you get when the app running on your PC can't connect to the server running on the SACD player.  Either the player is not running the sacd_extract app on the player (so the app isn't "listening" on the network), the IP address of the player is incorrect (as specified in your cmd file on your PC), or less likely, your PC is not on the same network (or there is a firewall in-between your PC and your SACD player (unlikely)).

 

Check you can ping that IP address from your PC, and then see if you can telnet to port 2002 on that IP address.  If you can do both, then the app running on your PC should be able to connect to the SACD player.

 

HTH!

 

Matt

[mutant_matt]

3 minutes ago, Phthalocyanine said:

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.

Yes and no

 

If you ping the SACD player from your PC, that just tells you that the SACD player is on the network.  This should work when the player is on and connected to the network at any time, and does not tell you anything about whether or not the SACD player is "listening" on any ports (either telnet/port 23 or the sacd_extract binary (port 2002).  By default, I don't think most SACD players are listening on any ports, as they usually act as network (media) clients, not servers (which is part of what the sacd_extract binary that runs on the SACD player is).

 

If you do a "telnet test" from your PC (something like: telnet <ip address> <port>, if you get a response, that tells you that the "server" (the sacd_extract binary running on the SACD player), is running and listening on the port that it uses (2002 I think in this case).  This is not to be confused with running a different script on the USB stick to enable a telnet server to run on the SACD player! (which you could then connect to from your PC using telnet on the standard telnet port (port 23).  I am suggesting simply using the telnet executable on the PC, to test/prove that the SACD player is "listening" on the correct port on the SACD player.

 

HTH?

 

Cheers,

 

Matt.

[mutant_matt]

You should be able to use telnet as a better connectivity test than just ping (which only tells you the SACD player is on the network).  If the sacd_extract binary is running on the player (after having opened the draw for you, you pop the disc in, and close the drawer), you should then be able to prove the sacd_extract is now "listening" on the network for incomming connections (typically sacd_extract.exe running on your windows pc (I run Linux, but that's not relevant here/right now), by doing a telnet test like this:

 

matt@linuxpc:  telnet 192.168.1.100 2002

Trying 192.168.1.100...
Connected to 192.168.100
Escape character is '^]'.

 

You will get no further, but you will have proven using telnet, that the "server" running on the player, is listening on the network (port 2002, and therefore, ripping should work).  Ping tells you the player is on the network, telnet (to port 2002) tells you if the sacd_extract server is ready and listening.

 

If the sacd_extract server is not running on the player you will get:

 

matt@linuxpc:  telnet 192.168.1.100 2002

Trying 192.168.1.100...

telnet: Unable to connect to remote host: Connection refused

 

or

 

matt@linuxpc:  telnet 192.168.1.100 2002

Trying 192.168.1.100...

Access denied

 

(depending on the local telnet client you are running on your pc).

 

 

If you were to do a "standard" telnet, like this (not specifying the port, it will then take the default (port 23)):

 

matt@linuxpc:  telnet 192.168.1.100

Trying 192.168.1.100...

telnet: Unable to connect to remote host: Connection refused

 

or as Phthalocyanine got (depends on the local telnet client how it reports this):

 

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

 

Both mean a telnet server is not listening on the target IP address (on port 23), which you would expect, unless you're running the autoscript that does run a telnet server on the SACD player, instead of the sacd_extract binary.

 

There are plenty of other network tools you can use to test for a server listening on any port you like on a networked machine, telnet is just one that tends to ship with most operating systems (though I think it's no longer part of the default Windows install since Windows7, but I could be wrong...)

 

HTH!?

 

Cheers,

 

Matt.

[mutant_matt]

On 17/05/2017 at 2:17 AM, Dick Darlington said:

I strongly concur with this post!

 

The telnet tack is a red herring in the case of the Oppos. You will flitter away hours of your life pointlessly. It doesn't apply to Oppos and it won't work. Just follow the non-telnet centric instructions. If you're lucky enough to find them that is. 

 

Fair enough, didn't want to create confusion, was trying to clarify and point out that:

 

1. telnet, when run solely on your PC (not on the player, which has been described as "the telnet method"), instead can be used as a network diagnostic tool to test/check if the player is running the sacd_extract binary, is listening on the network, and ready for "ripping".

 

2. It's a better test than ping, as ping only tells you that *something* is on the network and replying to that ip address (which the player will do when it's on and connected to the network, without any of these tools running).  The telnet test as per point 1, tests the ip adresss *and* the port required for the ripping tools to work.

 

I didn't at any time suggestion people should try running a telnet server on the player itself (using the alternative autoscript files), which is an entirely different thing (gives you command line access to the player itself).

 

HTH!?

 

Cheers,

 

Matt.

[mutant_matt]

17 minutes ago, haggis999 said:

The advice for using the Oppo was to turn off disc autostart settings. Does the Pioneer also have such configuration options?

 

Wasn't there also some Pioneer 160 specific autoscript files which differed slightly from the Oppo/Cambridge ones?

[mutant_matt]

If both NICs (Network interfaces) in the laptop and player are gigabit, then any straight-through, or crossover cable will work.  I suspect the laptop is gigabit but the player probably isn't.

 

If so, a crossover cable will work, but you'll have to set static IPs on both the laptop and the player (on the same subnet), for this to work.  There is nothing wrong with a 10m cable, unless it'll just be in the way.

 

If there is a network router in between then the cabling point still stands (either is fine (as long as the switch in the router is gigabit), but you shouldn't need to set static IP addresses, as the router will most likely be running a DHCP server, and assign both the laptop and player dynamic IP addresses (which will change from time to time, so I'd usually advise setting the player to static, so it's IP address is, err, static * ).

 

HTH!

 

* - this can also be achieved with a DHCP reservation, if your DHCP server (in the router), has that feature.

[mutant_matt]

I'd use a wired network wherever possible, just to be sure of reliability (wifi is pretty horrible for things that don't need to be mobile (which depends very much on where your devices are)).

 

Also then, you always know that the network won't be the cause of any problems or slow-downs, which wireless is often both.

 

 

[mutant_matt]

ted_b for *president! (of this thread, at least! )

 

Delete as applicable for the type of leader you have in your country... (though I'm not sure you'd describe Theresa May as a "leader" in any sense, here in the UK! )

[mutant_matt]

12 hours ago, jkenton said:

Re-downloaded, just to be sure, from Sonore site iso2dsd_OSX_v6

When I hit Execute I get message:

"Failed to connect

libsacdread: Can't open 172.27.35.132:0 for reading"

 

 

This is a connectivity problem.  Either the IP address of the SACD Player is incorrect (can you ping it), possibly the port has been specified incorrectly (or the player isn't "listening" (problem with the code run from the USB stick)).  From your post the port specified is 0 and should usually be 2002.  Here is the output when I run this:

 

sacd_extract -i 192.168.123.159:2002 -P -I

 

with my SACD player turned off:

 

libsacdread: Can't open 192.168.123.159:2002 for reading

 

That is, assuming it was previously working for you, which would rule out problems with the player not listening for the connections from your computer.  If the player isn't "listening", then you'll get the same error, but if it is, the zero for the port number in your case looks like the problem to me!

 

HTH!

[mutant_matt]

10 hours ago, jkenton said:

Mutant_matt , typing in 2002 did the trick!!

I can't tell you many hours I spent trying to figure this out.

A BIG Thanks to you and all who have helped me!

You da man !

 

No problem at all.  When you work in IT, and the world is increasingly moving into that realm, you can fix all manner of real-world problems relatively simply, with a little knowledge (in this case understanding IP addressing *and* IP ports).

 

Ted has been a great help to me personally, so I like to give back where I can

 

Cheers,

 

Matt

[mutant_matt]

Personally, I use Amazon a lot of the time (some of them are quite a nice size), but also discogs.  Between those two, I've never been disappointed.

 

HTH!

[mutant_matt]

Just had a thought - I don't support there is something like AccurateRIP for SACD ISOs is there?

[mutant_matt]

Interesting - thanks

 

Why not though?  What is it about SACD transports that mean they don't suffer the same problem as CD transports?

 

If anyone is interested, just for the hell of it, and to see what results we get, we could post a few MD5sums (or one of the SHAs, the hash algorithm doesn't really matter)?

 

Anyone curious? (or am I the only saddo here? )

[mutant_matt]

You need to carefully follow all the instructions which mention that you can't just copy the files, you need to edit the sacd.cmd file on the USB stick to put the IP address of your player in there.  Otherwise, your computer won't know where/how to contact your player.

 

Also make sure you can ping the player from your computer that you are going to do the rip from, by the IP address that you put in the sacd.cmd file on the USB stick.

 

Cheers,

 

Matt.

[mutant_matt]

Doh, sorry - I didn't read the question correctly.  I've not used ISO2DSD myself, is there a port option along with the IP address in ISO2DSD?  Regardless, for all of the utils that connect to the player:

 

It sounds like the player is not "listening" on the IP address/port, or there is a connectivity problem.  To try and diagnose, try pinging the player first (from the command line/command shell (Mac/Linux), Command Prompt/cmd.exe (Windows)):

 

ping <IP_address_of_player>

 

e.g. ping 192.168.1.50

 

If that works (you get a response like):

 

PING 192.168.1.50 (192.168.1.50) 56(84) bytes of data.
64 bytes from 192.168.1.50: icmp_seq=1 ttl=58 time=6.19 ms
64 bytes from 192.168.1.50: icmp_seq=2 ttl=58 time=6.21 ms
64 bytes from 192.168.1.50: icmp_seq=3 ttl=58 time=6.35 ms

64 bytes from 192.168.1.50: icmp_seq=3 ttl=58 time=6.35 ms

 

If it doesn't work (you get a response like):

 

PING 192.168.1.50 (192.168.1.50) 56(84) bytes of data.
From 192.168.1.50 icmp_seq=1 Destination Host Unreachable
From 192.168.1.50 icmp_seq=2 Destination Host Unreachable
From 192.168.1.50 icmp_seq=3 Destination Host Unreachable

From 192.168.1.50 icmp_seq=3 Destination Host Unreachable

 

 

If you can ping then try a telnet test:

 

telnet <IP_address_of_player> 2002

 

e.g. telnet 192.168.1.50 2002

(note the single space between the end of the IP address and the start of the port, it's important)

 

 

If it doesn't work (you get a response like):

 

Trying 192.168.1.50...
telnet: Unable to connect to remote host: Connection refused

(you'll get this if the player isn't "listening", you can prove this with it off)

 

 

If it works (you get a response like):

 

Trying 192.168.1.50...
Connected to 192.168.1.50.
Escape character is '^]'.

 

 

If you can ping and telnet, then the player is listening ok and your computer can connect to it ok.  If all these are true then sacd_extract and ISO2DSD should be able to also connect and do their thing.

 

I don't think you can change the port used (it's hardcoded into the binary that runs on the player), so as long as you target port 2002, on the correct IP address, and you have connectivity, it should work.

 

HTH!

 

Matt

[mutant_matt]

Yes.  I tried using this (which was designed for the chipset in a CA 752BD) in my CA 751BD and whilst it looked like it was working (the messages on the screen and the opening of the tray), it never did "listen" on port 2002, so I was unable to do the ripping.

 

So, if you can confirm it's listening or not (my my above port testing), you'll know there is a problem with something to do with the files on the USB stick (or in some people's cases, the stick itself).  Indeed, one of the things that could be "wrong" is the files don't match the player.

 

HTH!

 

Matt.