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

[Dick Darlington]

Hello everybody, I'm new to this Forum and I get here beacuse of finding a link in Google where I'm able to rip my SA-CD in DSD with my Oppo / Cambridge Audio devices. Now I find this thread and I'm a Little bit confused. Do I have to read all 1705 Messages or can I find a sort description somewhere - maybe with a link for downloading the actual tools and programms I will need?

Or can someone tell me the message number where the actual Information starts?

Thank you for your help!

 

I feel, nay felt your pain! I have an Oppo 103 and a Mac and after about 3 hours of back and forth between the family room and my study and chasing my tail with links to different posts and elsewhere I prevailed. It tuns out it is very easy and I prostrate myself to kiss the feet of all the smart people that made this possible.

 

First thing is to ignore EVERYTHING referring to telnet and ABCDEF... scrolling across the screen. That was then this is now. Meaning the instructions on post #26 (http://www.computeraudiophile.com/f11-software/sacd-ripping-using-oppo-or-pioneer-yes-its-true-29251/index2.html) assume a newer simpler method that doesn't involve telneting to your Oppo. The second thing is to use the ISO2DSD GUI program available from Sonore on your computer end. (Don't have the link handy. Google it.)

 

If you have a Mac then there may be a few steps required to convince MacOS to allow the ISO2DSD to run. If that becomes an issue let me know and I will elaborate.

 

Third thing is that you must put the AutoScript folder *containing* the 3 files on the root of the USB stick as per the OP's instructions. On *my* Oppo it would not work with the files at the root level.

 

Good luck. Godspeed. And may The Force be with you.

[Dick Darlington]

21 hours ago, riskylogic said:

 

I have just about my entire collection ripped to my network hard drive, which I can direct play from using my ipad.  So, when deciding to play, what is not ripped is largely forgotten.  Now that I can rip SACDs, a) they are back in my collection, and b) I'm buying more of them.

Precisely! What HE said! 

 

I thought I had purchased my last SACD a few years ago but I'm starting to buy again now that they've magically become as convenient as my hi-res digital downloads (and often less money to boot! ?)

[Dick Darlington]

1 hour ago, One and a half said:

Been mentioned at least twice in this thread that the UDP-203 cannot rip a single SACD.

Me thinks the poster was inquiring about future potential rather than the present state. Newcomers to this thread, who will naturally focus on the most recent several pages first, might find genuine answers to his/her question useful. Come to think of it, I, being an Oppo fanboy/girl nigh on the brink of taking the 4K flying leap, would also be interested to know if there is a Manhatton Project like effort underway to crack that nut. 

 

Page One, here I come. (start thinking Brave Heart now ...) FREEDOMMMMMMM!!!!

[Dick Darlington]

7 hours ago, 1markr said:

Hey folks, the latest firmware version for the OPPO 103 is BDP10X-83-1226 (from late January).  I haven't updated my player yet; is anyone using this firmware and successfully ripping SACDs? I just want to make sure it doesn't break that capability before I update my 103. Thanks!

 

We're all waiting for you to be the crash test dummy ? 

[Dick Darlington]

1 hour ago, haggis999 said:

I eventually found a post dated 2 Oct 2016 on p44 that quoted the following link, which contains that version of sacd_extract.exe.

https://github.com/sacd-ripper/sacd-ripper/releases

 

Unfortunately, that just gives me a different error, as shown below. Other things worked as expected, i.e. the Oppo's disc drawer opened automatically after I plugged in the USB memory stick containing the Autoscript folder (after which I loaded an SACD and closed the drawer). Perhaps I'm using the wrong version of Autoscript...

 

G:\sacd_extract>sacd_extract -i 192.168.1.84:2002 -P -I
Failed to connect
libsacdread: Can't open 192.168.1.84:2002 for reading

If sacd_extract isn't working for you, it might be worth trying the Sonore iso2dsd GUI. The MAC OS version works great for me. I can't speak for the Windows version, but presumably it works. Just google "Sonore iso2dsd windows" and it'll come right up. 

 

Btw I feel (or rather *felt*) your pain!  Took me a whole afternoon to find the needle in the haystack of this thread and get it working on my Oppo -- that Telnet thing was a major red herring! -- but in the end it turns out to be super easy. The hard part comes later; trying to convince Lloyds of London why they should insure your Oppo BD-103. ? 

[Dick Darlington]

5 hours ago, wanthalf said:

Please, forget about the telnet! I will repeat my earlier experience again:

• you do NOT need telnet at all
• telnet daemon will not start on the Oppo, it is probably not available there - do not even try using the autoscripts trying to run the telnet daemon on Oppo: the scripts will fail and they will not be able to continue and start the sacd extractor server anymore!

The only proper thing your autoscript should do on the Oppo is copying the sacd_extract binary to the player and running it there. The other scripts trying to run telnet and set the buffer are obviously meant for the other (Pioneer?) players.

 

BTW: The Oppo HAS some ports open by default (I did a port scan). I suppose those ports are open for the remote control apps (for smartphones and other devices).

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. 

[Dick Darlington]

8 hours ago, ted_b said:

not for multichannel they don't. 

I can't speak for the truly newer Oppos but I have a 103 and it definitely plays MC DSD (up to 5.6 MHz) and FLAC (up to 192KHz). I *think* it plays ALAC same as FLAC but I can't remember for certain. 

[Dick Darlington]

18 minutes ago, Dick Darlington said:

I can't speak for the truly newer Oppos but I have a 103 and it definitely plays MC DSD (up to 5.6 MHz) and FLAC (up to 192KHz). I *think* it plays ALAC same as FLAC but I can't remember for certain. 

Okay I believe I misspoke w/r/t the 5.6 MHz DSD. A vague memory of the limit being DSD64  (2.3 MHz) and a google search later I stand corrected. ?‍♂️ 

[Dick Darlington]

Great post and a great segue to the elusive "back on topic"! (and thank The Goddess you didn't call bullshit!) 

[Dick Darlington]

Damn I LOVE a happy ending! The difference between wielding SACD ripping power or not is tantamount to a Lieutenant wearing the gold vs red shirt on the Away Team. 

[Dick Darlington]

Lessons Learned Along the Way on my Journey to Sony BDP-S590 Ripping Nirvana 

 

‼️ Many kudos and thanks to you, Phthalocyanine, for expanding the universe of rip-capable players ‼️

 

For nigh on a year I’ve been happily ripping SACDs on my Oppo 103 thanks to ? Ted_B ? and other earlier contributors.  And yet, the "monsters under my bed" like fear that I would one day wake to find that my Oppo had bitten the consumer electronics dust ?? and to know that I was again in the shackles ⛓ of servitude to physical media has lingered all the while.  As the challenge and expense of finding a replacement ripper has increased over the past year, so too has been my therapist’s?‍?net worth???.

 

Needless to say I was quite chuffed??to learn of this windfall expansion of the rip capable devices pool.  I wasted no time in snagging an S590 for $35 (more than half of which was shipping ?) on eBay to serve as a backup ripper.?? Thank you again Mr. P!

 

It is working beautifully now, and I am delighted at no longer carrying all of my eggs in one basket, but this did not come without an afternoon of spinning my wheels in frustration ? and a growing concern that even if the exploit worked on some S590s it may not necessarily work on all.  Fortunately that was not the case.??

 

My initial attempts were thwarted by a few trivial issues and a soupçon of ill luck as it turned out.  So, I figured it might be worthwhile to share with the community the details of my brushes with some easily avoidable pitfalls.

 

Before I proceed, a few caveats and contextual notes may be in order:

• The following pertains to my recent experience with a Sony BDP-S590 specifically. However, some issues and observations may have broader applicability.
• The computers involved were a Mac running macOS High Sierra AND a PC running Windows 10.  Both were capable of ripping from my Oppo 103 without issue via my dedicated Oppo configured USB stick.  The point being: I was starting from a position of basic knowhow and a computer configuration and network environment that was verifiably working with the Oppo BDP-103. 
• My S590 is running firmware M12 R.0430 (the last supporting SACD-R as per Mr. Phthalocyanine).  I was unable to confirm the year of manufacture.

The obstacles I encountered with the S590 boil down to these four problems that will be described in full detail below:

1. USB stick partition table problem (of a benign nature)
2. Discrepancy in AutoScript files for Telnet method obtained via a posted Dropbox link
3. USB stick partition table problem (of an insidious evil nature)
4. My misinterpretation of the finer points of Mr. P’s autoload “workaround”

The details of each are as follows; not necessarily in the order that they were kicking my arse:
 

1. USB drive partition table type not compatible with S590 -- USB stick partition table problem (of a benign nature)

 

After getting nowhere with my initial “server method” attempts, I fetched a second USB drive, and used the Mac to erase it and create a fresh FAT32 volume and prepared it with the necessary “Telnet method” AutoScript folder and files.  When I inserted it in the rebooted player however, an error message “The USB device connected to this unit’s front panel is not supported.”  I replaced it with my original drive, and no such error (although it was still useless for ripping at this point).  I tried a third stick of a different model with a fresh FAT32 volume with no files and it too resulted in the USB device unsupported.

 

As it turned out, the problem was due to the partition table type being incorrect in the case of the “unsupported” USB drives.  The Mac defaulted to creating a GUID Partition Table (GPT) instead of the legacy Master Boot Record (MBR) table type.  A FAT32 volume can be created on either, but only a drive with an underlying MBR partition table will work.

 

Takeaway:  Your USB drive MUST be initialized as an MBR partition table device.  That may or may not be the default on your computer.  If in doubt an easy check is to first insert your intended USB drive in the S590 prior to setting up the AutoScript folder to confirm that it is recognized as a supported device.

 

2. Discrepancy in Telnet method AutoScript file

 

Having been setup to rip from my Oppo, which only supports the server method, the Telnet method was all new to me.  The instructions that I first found were in Ted’s post of July 22, 2016, which includes a Dropbox link to a Telnet method AutoScript folder.  It is possible that I overlooked a more recent link, but it is the one I found first and so it is someone else my come along and make the same misstep.

 

I repost the link here: https://www.dropbox.com/sh/eu48sjfmrgtxdan/AAB1Q8x6vRWMQAt1egXOevYQa?dl=0

 

That is what I used to create my USB drive, but alas nothing happened upon insertion and my attempt to Telnet from my Windows 10 PC resulted in the “connection refused” pound sand message.  Eventually I noticed that the contents of the AutoScript files had “inetd” in the Telnet server launching line instead of “telnetd” as shown in the text of Ted’s post.  When I replaced the “inetd” in the AutoScript files with “telnetd”, that was when my S590 fortunes began to change for the better although I wasn’t quite out of the woods.

 

Takeaway:  Although “inetd” is presumably the correct daemon to launch on other players to enable Telnet access, it does not seem to be the case for the Sony S590.  Inspect your AutoScript and AutoScript.TSS and if necessary replace “inetd” with “telnetd” before attempting a Telnet connection to your S590.

 

3. Just plain evil USB drive partition table (or lack thereof) anomaly

 

As luck would have it I was using my original, randomly selected from my stash, 16 GB Kingston USB drive when I made my aforementioned Telnet method breakthrough.

 

BTW, this was the drive I originally tried to use for the server method with no success past the point were the tray opened.  Attempts to connect with sacd_extract from Windows crashed and burned every time.  But now I had repopulated it with a working telnet AutoScript and I was able to telnet in and logon as root. Wahoo!

 

My euphoria was short lived.  When I attempted to cd over to the USB device I was presented with the “no such file or directory” message.  And sure enough, /mnt/sda1 did not exist but rather the USB drive had been auto-mounted as “sda” and not “sda1” as assumed by all the AutoScript variants I’ve encountered.

 

Aha I am thinking; the S590 uses sda whereas the others use sda1. (I was wrong of course but it made sense at the time.) NO WONDER it didn’t work with the server method AutoScript!  So I grabbed a different USB drive and set it up for the server method but with sda1 changed to sda; and exclaimed THESE HANDS ARE TOUCHED BY GOD!

?‍♂️ 

I waited a few minutes for the champaign? to chill and tried again.

No joy.??‍♂️WTF?

 

By using the rear USB port for my Kingston telnet drive *after* rebooting and inserting a different USB drive in the front, I could “ls /mnt” and see where the front drive was mounted.  Note that in this case, the rear inserted Kingston drive mounted at “sdb” rather than “sda” since it was inserted second.

 

I repeated this for several drives and in every case the other drive ended up at “sda1”.  WTF?  So basically “sda1” was correct for every single USB drive I had EXCEPT for the one I randomly chose at the beginning and was still trying to use.  That one always mounted as “sda” (unless it was inserted second whereas it would mount as “sdb”).

 

So what was different about the Kingston?  I couldn’t believe that the brand was a factor.  The clue to solving the mystery was the way it appeared within the Disk Utility app on my Mac. Every external drive is displayed as a top level “external physical disk” e.g. “disk3” having one or more sub-level “external physical volumes”, e.g. “disk3s1” underneath; except for the Kingston.  It shows up as an “external physical volume”, “disk7”, at the top level with no sub-levels.

 

The Kingston works normally in every way and I’ve since made it work in both Telnet and server modes by changing sda1 to sda, but it is truly special.  Too bad that’s the one I picked initially.  Any other of my MBR partitioned USB sticks would have worked in server mode on the first try.  Ah well.

 

After looking at the Kingston with Test Disk and some other tools (albeit not PTEDIT which I no longer have a copy of) it is a “non-partitioned disk” and considered to be invalid by those tools.  Clonezilla and GPartEd both choke on it, but Windows, macOS, and the Linux on the S590 seem to fully tolerate it’s alternative orientation.  I cannot replicate the weird structure to save my life and I’ll probably die never knowing how it came to be, but there it is.

 

Takeaway:  Don’t be unlucky.?

 

4. Misinterpretation of “autoload workaround” instructions
(IOW: I’ve been stupid so you don’t need to.??‍♂️)

 

I completely misunderstood (to the point of getting it arse backwards) Mr. P’s explanation of his fortuitous (and impressively so!) discovery of the autoload workaround.  I was believing that after toggling between 2-channel and multi-channel in Music Settings but before starting the rip, the disk had to be reinserted in order for the change invoked by the toggle step to take affect.  But in fact the rip operation can be done immediately after the toggle, but will not work after reinserting a disk unless and until the Music Settings toggle step is repeated.

 

Takeaway:  Starting from the point where the sacd_extract server is running on the player and the inserted disk has been autoloaded: toggle the setting in Music Settings and then proceed with the rip via sacd_extract or if you prefer, iso2dsd. The toggle action must be repeated immediately after each subsequent disk insertion.

Well there you have it.  May The Force be with you, and may the Goddess light your way.

 

Dick

 

PS:  Note for Mac users. FWIW, as others have mentioned the option to select MS-DOS FAT32 is no longer present on newer versions of macOS; only MS-DOS FAT.  This is not a problem and there is no need to find another means of formatting your USB drive.  If you choose MS-DOS FAT it will actually create the volume as FAT32 as necessary based on the size of the drive.

 

PPS: I have informed my therapist?‍?that her services are no longer required.

[Dick Darlington]

41 minutes ago, HenkNZ said:

Also, I looked at the script files, both are the same, except for one having the .tss extension.  Is this right?

 

Are you including the “:2002” port number in the dsd2iso server address field?

[Dick Darlington]

8 hours ago, Phthalocyanine said:

The third line launches the executable program telnetd, which is located in the directory path /usr/sbin.  So if the text in the dropbox file you used inetd instead that’s something different from what I got, and by editing it you got it back to what I’ve been using.

 

But interesting enough according to Wikipedia

 

Often called a super-server, inetd listens on designated ports used by Internet services such as FTP, POP3, and telnet. When a TCP packet or UDP packet arrives with a particular destination port number, inetd launches the appropriate server program to handle the connection.

 

As you note in your take-away, launching inetd could conceivably work on some systems, but not, it seems, the Sony BDP-S590. 

@Phthalocyanine thank you and thanks for the additional info.

 

Until this morning, I have wrongly believed that the Telnet method is not possible on the Oppo for some reason I knew not what.  My first attempts with the Oppo last year were unsuccessful until I aborted the Telnet method and went with the server method.  I *think* I remember finding a post around that time stating that the Oppos don't have Telnet available.  

 

Maybe I dreamt it; I don't know but I subsequently posted that bit of misinformation myself many months ago, and so if anyone comes across that, please ignore! 

 

I decided to revisit it this morning and lo and behold Telnet works beautifully on the Oppo after all.  It even displays the scrolling "ABCDEFG..." just as stated in @ted_b's instructions.  One thing I forgot to mention in my post yesterday was that the scrolling letters don't manifest on the Sony S590; at least not for me.  What I get instead is the display set to all zeroes, i.e. "0000".

 

However, as it turns out the Oppo does in fact require the "inetd" in the script and NOT "telnetd" as in the Sony's case.  The Oppo contains both the inetd and telnetd binaries in /usr/sbin whereas the Sony has only telnetd.  I looked at the running processes on the Oppo and both inetd and telnetd are running by the time I logon as root; so apparently the former ends up launching the latter. Try as I might I could not set up the script to launch telnetd directly on the Oppo though.  I am guessing it requires so command line options that are supplied automatically by inetd.

 

Soooo ... I set up a Telnet method USB stick that works for both players by including both daemon launch lines with a 1 second wait in between as follows:

 

#MTKAT 0.xx script

CLI(CLI_exec echo root::0:0:root,,,:/root:/bin/sh >/etc/passwd)
CLI(CLI_exec /usr/sbin/inetd &)
SLEEPMS(1000)
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)

 

I then have a second folder, "SACD_Extract" at the root level containing both "sacd_extract" (for the Oppo) and "sacd_extract_160" (for the Sony) and finally a set of text files corresponding to each that I can "cat" in the terminal window to jog my memory in regard to subsequent commands I need to enter.

 

@HenkNZ, I am a loss for suggestions beyond what others have already offered for your case other than you might want to try the Telnet route so that you can manually run sacd_extract on the player side to confirm that it runs okay and then to see if it reacts in anyway when you try and connect with iso2dsd from your Mac.  The caveat here is that Apple decided to protect us all from ourselves and took the telnet client away from us in High Sierra so you will need to find a PuTTY like alternative for your Mac first if you want to go down that path.  Whatever the problem is you can bet it's something really simple.  It always is.  In hindsight anyway.  Good luck!

[Dick Darlington]

4 hours ago, Phthalocyanine said:

@Dick Darlington

 

 

Getting the Oppo to work with telnet opens up so many doors for trouble-shooting.  Great work!

Did you do any local USB drive ripping on the Oppo using telnet?

The common wisdom on the thread had been that the Oppo did not work with the telnet method.

Your universal telnet USB drive script will be extremely useful for testing out other possible SACD ripper BD players.

By the way, I have never seen the scrolling letters on my Sony.  I always assumed it just doesn’t work on that model.  I never noticed the display set to all zeroes, either.  But I’ll look for it in the future.

@Phthalocyanine Ha I expect it’s always worked by virtue of an earlier contributor but some people like me tried it with a different AutoScript ... possibly one changed to work with the Panasonics ... and then “I tried with the Panisonic script with no success” became “oppos can’t do it” LOL. In fact I’m inclined to suspect that the so-called discrepancy in the script I started with for the Sony *may* have been due to it being toggled back to “inetd” for Oppo compatibly at some point. 

 

And no I stopped at confirming that I could manually ? sacd_extract in server mode and then rip from the Mac.

 

That said it seems the Oppo has an advantage for Mac users that prefer to rip locally. Unlike the Sony, the Oppo supports ExFAT in addition to FAT32. And unlike NTFS, ExFAT is supported on BOTH macOS and Windows 10. AFAIK there is no 4GB file size limit under ExFAT.  So to use a metaphor near and dear to my heart — fine ? and great ? —  for persons having a direct-to-USB-stick orientation, I would say that the Oppo pairs well with the Mac oriented and the Sony complements the Windows folks. Of course none of that applies to ripping over the network which is what I prefer.  

[Dick Darlington]

12 hours ago, wanthalf said:

Wow! So great you found out! I always wished to telnet to the Oppo and have a look around. How did you find out? Just trial&error?

 

Well after spinning around trying to get the Sony working until I noticed my script said inetd instead of telnetd as it was presented in a post I just went on a hunch that whomever put it out on Dropbox might have changed it for a reason. One that predated the Sony discovery. So I gave it a try and you could have knocked me over with a feather when I saw that ABCDEFG start to scroll lol. I just figured I came late to the party that everyone else was already enjoying. 

 

12 hours ago, wanthalf said:

I also wonder who found the CLI_app commands and how? There is surely more of them, I guess.

...

The inetd might be found by trial&error, but the CLI_app codes cannot be guessed without some internal documentation.

 

Yes absolutely. Where most of that stuff in the scripts that make this work came from I’d love to know! And then there’s the sacd_extract binary that has source and a really smart developer behind it but alas it is a mysterious black box to me. I tried googling for info on the CLI / AutoScript stuff and came up with zilch. Only hits I got were from this and the myriad similar forums on this topic. Ah well. 

file

[Dick Darlington]

7 hours ago, wanthalf said:

I'm probably already losing my mind... found the flash disk I used last time, checked the scripts and the call to inetd is there! Started my Oppo with the flash drive and... the telnet connection works!

 

? GOOD LORD!  Are you saying you went back to the very same flash drive that you made the original attempt with, and tried again without any modifications and it worked?  That’s crazy and even more puzzling than my similar mind-losing experience!

 

This morning I looked at my original “Telnet method” subfolder from which my flash drive was built. I noticed that for whatever reason the files both had a .txt extension, e.g. AutoScript.TSS.txt, which was not the case in my other variant folders. So until I read this post my theory was that I had either downloaded improperly named files, or done it to myself after the fact and that’s why it didn’t work last year.  But now a fog of mass insanity induced by a malicious alien race orbiting the ? at the time seems as good an explanation as any. ??‍♂️ 

 

PS:  My therapist?‍?has just had a weekly slot become available.  

[Dick Darlington]

6 hours ago, Spike44 said:

Just bought a Sony BDP-S590 to rip some of my SACDs, but still can't get a telnet connection to the player. (.....Could not open connection to the host, on port 23: Connect failed) - ping is ok.

Who gives him the ability for a Telnet Connection? The autoscript files or is it the player himself?

Is the firmware revision important for this?

I hope, someone here can help me with my problem!
Otherwise, I'll throw the box out the window soon.

 

 

@Spike44 Don't throw it out the window!  It will work great once you make it to the other side of the minefield.

 

Like @dtblair pointed out, it is important to be mindful of case sensitivity of file names, commands, and such given the Linux OS on the player.  That said, I am not certain if FAT32 fully supports case sensitivity because I can name the AutoScript folder, "autoscript" or "AutoSCRIPT" or whatever and it works as long as the AutoScript file is named correctly case-wise.  That may not be the case (no pun intended if I were to use NTFS).

 

Here's a few more things to try, keep in mind, and look at:

 

1. Always start with a freshly booted player.  Power it off and back on between attempts.  If the drive is properly formatted it will mount at /mnt/sda1 on the first insertion.  But if you remove it and reinsert it or a different drive it will mount as "sdb1" and so on.  So if you remove it and find and fix a problem with the drive and reinsert it before rebooting it probably won't work anyway.
2. If you hold off on inserting the flash drive until the player is fully booted then you can look for a few indicators that will help narrow down the problem.  If you're ?. 

• After you insert the flash drive look at the TV display and if it pops up a "USB device not supported" error message then you probably have a partition table or volume format problem.  Go directly to jail.  Do not pass Go.  Do not collect 200 quid. Confirm that it is an MBR partition scheme.  Confirm that the volume is formatted as FAT32 or NTFS and not ExFAT or something else.  Confirm that there is only one partition on the disk; no hidden system partitions that are likely to hose you.
• If it likes the USB drive then adjust your gaze to the players alphanumeric display.  The display should change to "0000" within a few seconds.  If it does not, then the AutoScript file failed to load.  The most likely reason is that you have recently angered the gods followed by "you screwed something up" as a close second.

1. (pretend this is 3). Since ping works and telnet doesn't, then you have mostly ruled out the "wrong ip" or network problem possibilities, but not entirely.  The other day -- a day that I was very much in the Goddesses favor BTW -- I too could ping but the telnet connection was refused although the "0000" was displayed as normal, leaving only "I screwed up" to sort out.  Turns out the dhcp assigned IP address had changed in the past day but something else was using the old IP.  That was just because I was too lazy to enter a static IP in my router for the play.

BTW, my player has firmware M12 R.0430, which is not the latest.

 

So take a look at the indicators in (2) above and see if that provides a clue that leads to the problem.

 

2 hours ago, dtblair said:

 

4. The Sony changes the directory name of the USB depending on the make of the thumb drive.  I have seen sda1, sdg1, and sdc1 as the names.

 

@dtblair I truly don't think the make of the thumb drive should have anything to do with the mount point designation.  AFAIK the first volume on the first partition of the first drive inserted will always mount as "sda1".  If you were to insert a second drive in the rear, it would be "sdb1".  Every time you insert a new drive or reinsert one of the others it will increment by another letter.  At least that's what I'm seeing.  I'm speaking of the S590 BTW.  Is it possible you were trying various things and removing and replacing the drive without rebooting?

[Dick Darlington]

Phone related screwup. Please ignore. ? 

[Dick Darlington]

9 minutes ago, dtblair said:

Am still getting the above error.  When it attempts to create the tmp file, where is this located?  Is the format of this file affected by the formatting of the USB?

 

Wish I had a helpful answer, which I don’t. But I doubt it is a formatting problem but rather differences in the players software wrt the S590 and others. What I really wish is that you could try the same USB drive on an S590 and see if the same issue occurs. Total baseless speculation but it could be as simple as the binary for sacd_extract is broken by some subtle change in the newer player’s runtime environment.   

[Dick Darlington]

3 hours ago, mutant_matt said:

In my case, I tried my CA751 (not 752), and the AutoScript stuff runs (it opens the drawer, it displays 12345678 on the screen), but it never listens on the network (on any port, I did a port scan just to be certain! (other than the "expected" ones like for uPnP/DLNA etc.)

 

 

@mutant_matt, Were you attempting to telnet to the player, or just have the AutoScript start sacd_extract in server mode? 

[Dick Darlington]

46 minutes ago, Rightsaidfred said:

Or do you think I should try and pick up a cheap Oppo from somewhere?

 

Or you could pick up a virtually free (for now) Sony BDP-S590. That’s what I did just to have as a backup for my Oppo. 

[Dick Darlington]

3 hours ago, klassikmann said:

Beware:
mysh.sh has to be UNIX-style textfile, i.e. end-of-line has to be coded by a single line-feed (\n); DOS-style textfiles are encoding end-of line as a two-character carriage-return + line-feed (\r\n). To avoid trouble I enclosed the mysh.sh to be copied as-is to the thumb device:

mysh.sh

I assume that the reason for my problems in the beginning with the old firmware was the wrong encoded mysh.sh.
Btw. AutoScript can be either style.

 

Ha @klassikmann, coincidentally I have been banging my head against a wall the past few days in frustration trying to test various things and basically identify that which I *know* to be factual versus that which is true only until I say it is; at which point it flips. Case in point: as soon as I said 0000 doesn’t display on the Sony if it’s booted with the USB drive already in, that was the last time I observed that behavior. Now it displays 0000 regardless. Probably will flip back now. Sigh. Call me old fashioned, but if I’m gonna lie to people, I think it should be MY idea! 

 

Well while testing USB drives formatting various ways and by various means I switched focus from my Sony to the Oppo and promptly got sidetracked by bizarre inconsistent behavior. Things worked differently from one attempt to the next. I would see the scrolling “abcdefgh” but could not Telnet. I would not see scrolling but Telnet worked anyway. Nothing worked. Everything worked. Round and round. Yes I was making tweaks to the AutoScript, they were tweaks I have long since known how to make without breaking things. Returned to a working reference script and made multiple incremental changes until it broke. Then I undid the last change: still broke. The change before. Still broke. On and on until back to original contents. Still broke. Meticulously compared working script with broken one: identical. Well except that the working one was 7 bytes larger than the other.  So you see where this is going: the DOS \r\n vs Linux \n line termination thing. 

 

But here’s the rub (and undoubtedly my next lie). The problem was NOT the *presence* of DOS style line terminators but rather the lack thereof on a few lines.  The resulting behavior depended on which lines lacked the two byte ‘0d0a’ line separator visible in the hex dump.

 

So. I had been editing the files on my Mac using TextEdit. Any time I hit Enter at the end of a line I introduced a non-DOS new line. That broke it. But if I copied a *good* line and edited it, all was well. Apparently TextEdit does not convert the whole file to a near-Unix Mac format upon save. Any existing \r\n line is preserved, but hitting Enter in the editor introduces a \n only. 

 

This seems arse backwards to me. The players are Linux based and yet the AutoScript.TSS file MUST be of DOS CRLF format. I confirmed multiple times (but one shy of my telling the truth) that starting with a purely Mac format text AutoScript.TSS  that will NOT work with the Oppo, I can use vi to convert it to DOS format and two things happen. It increases 1 byte per line in size and it works!

 

Now that is for the Oppo. I took a break short of going back to the Sony. Based on you’re results I am certain I will find that the Sony doesn’t care ... for AutoScript that is. I’ve checked the roster and your name is not listed as a member of the Liars Club. ? 

 

PS: afaik based on Apple’s vi commands, it recognizes three distinct formats: dos, unix, and mac. The implication that the mac format is different than unix as well as dos. I *thought* I tried converting to unix and it didn’t work either, but at this point I don’t believe a damn thing I say. ??‍♂️ 

[Dick Darlington]

Are we talking Windows or Mac here? The reason that I ask is that I am virtually certain that on the Mac the Sonore is just a GUI front end for sacd_extract, but I’m not sure that is the case for Windows. In either case an ?s to ?s context may be useful at this point. No pun intended. Sike I lie. 

[Dick Darlington]

9 hours ago, JuanDG said:

I'm using a Mac and a cheapo EMTEC 8GB flash drive. The trick for formatting the flash drive on MacOS is to use the Terminal to wipe it clean first. Plug-in the flash drive, open terminal and type `diskutil list` and write down the path of the usb drive, for instance /dev/disk3. Then wipe it by typing `diskutil eraseDisk FREE TEST /dev/<your disk path>` on the terminal. After that you can go back to Disk Utility and click on `Erase` and the option to set it as Master Boot will be present again.

 

Congrats @JuanDG and thanks for sharing helpful details!

 

FWIW I have put together a few documents with some how-to type information specific to Mac users focusing on the USB media preparation (i.e. formatting) and macOS network tools (e.g. telnet) respectively.  It appears that the lion's share of people on this thread are Windows based and consequently important Mac specific details, such as what @JuanDG has pointed out w/r/t formatting the flash drive, are discussed infrequently. 

 

The first document is a somewhat in-depth discussion USB media formatting and includes very detailed macOS based step-by-step instructions, GUI based and command line based and covering a variety of formatting file system and partition scheme options.  It also addresses player compatibility (or lack thereof) with the available formatting choices.  And finally, it provides an array of NTFS file system solutions and how-to information for Mac users.

 

Although this document is primarily targeted toward the Mac user audience, it covers media format to player compatibility, which is inherently OS independent, and so there is a fair amount of general information applicable to Windows users as well.

 

The media formatting document can be found here:  "The SACD Ripper’s Guide to the macOS Media Formatting Universe"

 

Next up is a guide that touches on Vogon poetry whilst aiming to familiarize the Mac user with some core network tools that are likely to need at some point during their SACD ripping quest.  This second document will also provide the macOS based reader with a gazillion options for coping with Apple's recent removal of the native telnet client.  This includes but is not limited to a detailed step-by-step procedure for installing Homebrew and from that the Apple telnet client.

 

The macOS network tools document can be found here: "The SACD Ripper’s Guide to the macOS Network Tools Universe"

 

A few notes on the above:

1. Neither of these documents is a guide to the ripping process per se but rather they are macOS centric guides intended to drill down into a few key areas integral to the ripping process.
2. These documents were written primarily for the benefit of the non-power user contingent of this community and as such contain a lot of detail that may seem like stating and/or depicting the obvious to many.  Rightly or wrongly, this was a conscious decision to err on the side of TMI.
3. Drink up ?, the World's about to end. ???

[Dick Darlington]

@LudwigvanMarbach if you used the usb drive for a Windows OS reinstall, then it is *likely* Windows formatted it with a hidden system partition at the beginning of the drive. And furthermore it may have used a GPT partition table. Off the top of my head I don’t know the Windows path of least resistance to reinitialize a drive with a  MBR partition table single partition of whatever file system (FAT32, ExFAT, NTFS) *your player* is happy with, but therein lies your problem I do believe.