Jump to content
IGNORED

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


ted_b

Recommended Posts

1 hour ago, LudwigvanMarbach said:

Thanks both for the wisdom. 

 

It was an OS X install actually but still I suspect something similar, having reformatted multiple times on multiple machines. I’ll try a FAT32 format from W10 and use that tool before hand. Will report back. 

 

@LudwigvanMarbach if it’s macOS we’re dealing with, then you surely have a hidden EFI partition at the start of that flash drive. It’s super simple to reinitialize the drive as a single partition MBR disc via CL or GUI. Instructions for both methods are in here:

 The SACD Ripper’s Guide to the macOS Media Formatting Universe

Link to comment
2 minutes ago, TODDCA said:

I currently have a Pioneer BDP-80FD player.

 

If you were getting a 2nd player as a backup for ripping SACD's only with no other intended use, which would you get knowing it may sit on a shelf but if you needed it you want some life left in it:

 

  1. A sony BDP-S590 used <$100
  2. Another BDP-80FD new ~ $230-250
  3. A used Oppo BP-103 $300-400

Just looking for other's thoughts.  One of mine is I could pick up two of the sony's put them in the closet and still not spend as much as the other options.

 

I picked up my S590 for $17 + $18 shipping on eBay for just that reason: to sit on the shelf as a hot spare for my Oppo. @Phthalocyanine‘s discovery ??? of the s590 and other Sonys was a quantum leap advance insofar as our options for snagging rip capable players whilst preserving assets better used to purchase more SACDs. ? 

Link to comment
6 minutes ago, vhrocks1 said:

 

 

 The drive causes the tray to eject, I put in the SACD, it is read and sits ready to play. I launch iso2dsd_gui.exe from my PC and the error comes up:

 

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

 

The solution to your problem is in @Phthalocyanine‘s guide for the S590. I think there’s a link to it somewhere one the 1st post. Basically you have to trick the player into unmounting the disk. Go into Music Settings and toggle the Stereo vs Multichannel setting *before* you run sacd_extract_160 be that directly or via a GUI front end. 

Link to comment
  • 2 weeks later...
4 hours ago, Eric3 said:

So, am I missing anything? Do I have to mess with Telnet, etc? Will the  3 files from the July,21,2016 work for the Sony?

@Eric3, as you are doing this on a Mac you may want to be forewarned of a *potential* gotcha w/r/t the AutoScript file:  if you edit the file using TextEdit then there is high probability of it breaking insofar as the parser on the S590 is concerned. This due to line termination differences. Basically any time you hit Enter to create a new line, you will introduce a line termination that is not compatible with the player, which will “break” that line (or the next; I cannot recall ATM). Depending on what part of the file you’ve edited, the script may work fine; may not work at all; or do the evil thing of both working and not working: e.g. the tray ejects but you can’t connect with sacd_extract/iso2dsd. It can be quite maddening and promote profuse Scotch consumption as you bang your head against the troubleshooting wall. Or so I’ve heard. Basically the Mac edited file may look exactly the same as the working file on a character by character comparison in TextEdit; but they are different as evidenced by the difference in physical file size. 

 

I’ve made copious notes on the specifics of the line termination issue (which AFAIK is most likely to bite Mac users), but I don’t have those with me ... okay full disclosure... but I’m too preoccupied with acoustic happy hour at the pub to search my cloud storage for said notes ATM.  

 

So just beware: TextEdit may be harmful to your AutoScript health. 

 

Good of luck and may The Force be with you!  

Link to comment

@Sevenfeet, if you’re old enough to remember Bewitched, it’s like “old Darren” and “new Darren”. The old Mac OS used one type of line termination and the newer iterations use another. I *think* the latter is the same as unix and the former was a single character termination that was not the same as MSDOS. The point is that New Darren is the same as Unix and yet that’s not what works for the S590 if not others. Current macOS is the same as Unix/Linux afaik and yet it is the Windows style line termination that the S590 wants. 

 

It seems opposite sauce to me but I can can assure you that if you type up an AutoScript file using TextEdit on the Mac it will not work but if you do it via Notepad on Windows it will. I can no ‘splain but it is what it is as they say. 

Link to comment
25 minutes ago, turnstile said:

 

This makes sense as to why I can successfully rip via the local USB method (Phthalocyanine), but was unsuccessful when it came to doing it via ISO2DSD on my Mac.  Do you have the Autoscript version w/ the -s command in line?

 

This is the reference copy I have that works for the Sony. I cannot recall whether the Sony wants the TSS extension whereas the Oppo does not or the converse but then you already know that if you’re doing local ripping so adjust as required. 

 

https://www.dropbox.com/s/l4ho1cch1yeotag/AutoScript.TSS?dl=0

Link to comment
4 minutes ago, Dick Darlington said:

 

This is the reference copy I have that works for the Sony. I cannot recall whether the Sony wants the TSS extension whereas the Oppo does not or the converse but then you already know that if you’re doing local ripping so adjust as required. 

 

https://www.dropbox.com/s/l4ho1cch1yeotag/AutoScript.TSS?dl=0

 

PS: the line where it loads the splitter kernel object doesn’t seem to be required for the Sony as far as I can tell. Maybe I’m missing something but I didn’t notice anything going awry when I deleted it. Presumably it is required or beneficial in some way for the Pioneers for which the AutoScript was originally created for. ??‍♂️

Link to comment
20 hours ago, Phthalocyanine said:

The following is the memory info returned on a Sony S590.

For those folks who better understand such things, how does its memory capabilities compare to the Pioneer 160 etc and/or the Oppo 103, 105?

 

 

Here's the memory info taken from my Oppo 103.  Obviously telnet was already running but I grabbed memory stats from both before and after launching sacd_extract in server mode:

 

Oppo 103 Memory Info

 

Before running sacd_extract:

-sh-3.2# cat /proc/meminfo
MemTotal:         316356 kB
MemFree:          161484 kB
Buffers:           13912 kB
Cached:            22660 kB
SwapCached:            0 kB
Active:            40592 kB
Inactive:          48052 kB
Active(anon):      25520 kB
Inactive(anon):    26552 kB
Active(file):      15072 kB
Inactive(file):    21500 kB
Unevictable:           0 kB
Mlocked:               0 kB
SwapTotal:             0 kB
SwapFree:              0 kB
Dirty:                 0 kB
Writeback:             0 kB
AnonPages:         52032 kB
Mapped:            12056 kB
Shmem:                 0 kB
Slab:               5828 kB
SReclaimable:       1708 kB
SUnreclaim:         4120 kB
KernelStack:        2296 kB
PageTables:         1112 kB
NFS_Unstable:          0 kB
Bounce:                0 kB
WritebackTmp:          0 kB
CommitLimit:      158176 kB
Committed_AS:     523448 kB
VmallocTotal:     385024 kB
VmallocUsed:       32388 kB
VmallocChunk:     322244 kB


After running sacd_extract in server mode:

MemTotal:         316356 kB
MemFree:          160464 kB
Buffers:           13812 kB
Cached:            22752 kB
SwapCached:            0 kB
Active:            42044 kB
Inactive:          47824 kB
Active(anon):      26752 kB
Inactive(anon):    26552 kB
Active(file):      15292 kB
Inactive(file):    21272 kB
Unevictable:           0 kB
Mlocked:               0 kB
SwapTotal:             0 kB
SwapFree:              0 kB
Dirty:                 0 kB
Writeback:             0 kB
AnonPages:         53304 kB
Mapped:            12216 kB
Shmem:                 0 kB
Slab:               5856 kB
SReclaimable:       1712 kB
SUnreclaim:         4144 kB
KernelStack:        2304 kB
PageTables:         1144 kB
NFS_Unstable:          0 kB
Bounce:                0 kB
WritebackTmp:          0 kB
CommitLimit:      158176 kB
Committed_AS:     549640 kB
VmallocTotal:     385024 kB
VmallocUsed:       32388 kB
VmallocChunk:     322244 kB

 

21 hours ago, Phthalocyanine said:

Interesting that you got the Sony to work without it.

 

My sense, based on what was discussed on this thread early on, is that the Pioneer needed this line (as compared to the Oppo 103/105, which were only other BD players known to work with the exploit at the time) because the Pioneer had less memory and needed this line to help buffer the rip.

 

Well it is what I *thought* I remembered explicitly testing for and concluding a few months back, but then again after all the bouncing around between the two players and all of the different things I was attempting to nail down, I figured I should double check to be certain and avoid adding another brick in the inadvertent misinformation wall. So...

 

I just ripped an SACD ISO over the network from my S590 using an AutoScript.TSS file that definitely did not have the splitter kernel object line present.  The rip went fine and seemed perfectly normal to me.  It started at around 1.9 MB/Sec and began climbing from there.  The final average reported by ISO2DSD was 2.39 MB/Sec, which surely would have been higher had the image not been on the small side.  It was only about 1.9 GB.

 

OTOH I have no reason to think the inclusion of the "insmod" line causes any harm even if it has no appreciable benefit.  The point being that I'm certainly not recommending it be removed for S590 targeted scripts; it's just that I don't use it myself.
 

Link to comment

MISINFORMATION ALERT

 

Severity: MODERATE

Offender:  @Dick Darlington

Offense:  Dissemination of fake news w/r/t AutoScript file name requirements for Oppo and Sony S590 players

Inculpatory Evidence:  see quoted SigInt below

 

22 hours ago, Dick Darlington said:

This is the reference copy I have that works for the Sony. I cannot recall whether the Sony wants the TSS extension whereas the Oppo does not or the converse but then you already know that if you’re doing local ripping so adjust as required. 

 

Disposition:  Convicted.  Sentence of 40 hours of listing to 128 kbps MP3 music ripped from low dynamic range CDs reduced to slap on wrist, specifically a timely release of an evidence based retraction/correction. 

 

"The above statement, which implies that neither the Oppo nor the Sony player is compatible with both the '.TSS' and extension-less AutoScript file name is patently false.  In actual fact, the name 'AutoScript.TSS' is accepted by and works correctly with BOTH players whereas the extension-less form, 'AutoScript', works on the Sony S590 but will not work on the Oppo 103.  Put another way:  the Sony S590 does not care about the TSS extension or lack thereof whereas the Oppo 103 requires it."

Link to comment
  • 2 weeks later...

@wl_lam, do you intend to rip directly to your PC over the network or do you plan to rip locally to the USB drive?  To put it another way: do you fancy the telnet method, or are you a server method kinda bloke? This matters since the procedures and the AutoScript file on the USB depart in many respects between the two. For instance you don’t need to worry about anything having to do with Telnet in the latter case. OTOH you will need to have the Windows command line sacd_extract.exe on your PC or the ISO2DSD GUI application. http://www.sonore.us/iso2dsd.html The GUI front end includes the aforementioned command line sacd_extract program btw. 

 

I will be happy to provide a link to the correct AutoScript.TSS file for your chosen method as well as the Linux (player side) sacd_extact program for your USB drive.

 

 

Link to comment
16 hours ago, wl_lam said:

Hi Dick,

I will try to rip locally to the USB drive. it seems that it will be easier.  Please share the link to the correct AutoScript.TSS file. 

 

@wl_lam and @Tonmeister, the following link will take you to a Dropbox folder containing a handful of resources including:

 

1. A universal AutoScript folder that supports both the Telnet and Server methods on (at the least) the Oppo and Sony S590 players.  The AutoScript folder contains the universal AutoScript.TSS file (which is highly annotated) and both variants of the sacd_extract Linux executable. 

 

2. Links to Sonore’s download pages for ISO2DSD and DSD2FLAC applications for macOS, Windows and Linux.

 

3. The computer-side binaries for the sacd_extract command line programs (macOS and Windows). Note these are also included in Sonore’s GUI front end. 

 

Dick’s SACD Ripping Stuff

 

You will not find instructions there, however you’ve already seen @ePhono‘s nice write up and since you are angling for local ripping AND a Windows bloke then @Phthalocyanine‘s Guide for the S590 should have you cookin’ with gas in no time. 

 

HUGE CAVEAT on universal AutoScript file: my heretofore latest version was tested on both the Oppo and Sony players and worked ?.  However (picture the late great Rodney Dangerfield nervously adjusting his tie) the minor changes I made today have not yet been tested. I plan to do that soon but as of this moment there exists the possibility that I introduced a fatal flaw. 

 

BTW, having done both methods, imho the telnet method is no more or less simple than the server method: they’re just different. Each has wickets potential pitfalls that the other does not. Both require your network connectivity to be sorted out or you don’t get to first base, etc. At the end of the day it just comes down to your workflow preference. 

 

Good of luck and may The Force be with you!  

Link to comment
  • 2 weeks later...
Just now, Dick Darlington said:

@wl_lam ??

 

Could be a flaw in the annotated AutoScript wrt the Sony players in that as written it will execute sacd_extract_160 *before* you can do the workaround. Try commenting out ALL lines executing sacd_extract_160 and enter the command manually *after* you do the workaround (or put in sleep mode). 

 

Ill have to go back and look at the script but it wasn’t my intention to have it launch sacd_extract_160 in local mode. 

 

Btw, I notice you’re up to ‘i’, ie “/mnt/sdi” which suggests you’ve made several attempts without rebooting. IOW possibly  sacd_extract_160 was left running from a previous attempt? You can do a ‘ps’ command to check and a ‘kill’ if necessary. 

Link to comment
7 minutes ago, mindset said:

A little off from @wl_lam's current direction, but for flexibility I feel it is better to always run sacd_extract_160 in the server mode, which can actually be used for local ripping as well by pointing to 127.0.0.1 (=local host) as the server address like this:

 

sacd_extract_160 -i 127.0.0.1:2002 -I

 

This way, one can do local/remote ripping without changing anything on the player side.  I tried this on my S390, and confirmed working.

 

 

Cool trick. Worth looking into if I’m pickin’ up what you’re layin’ down!

Link to comment
28 minutes ago, David_B said:

Thank you. Yes, it is 192.168.1.75 : 2002 and as far as i can tell is doesn't change. I just don't get it. I do everything in the instructions it says to do, and when I click on execute, nothing happens.

sonore sacd crap.jpg

 

Are you able to ping the Oppo at that IP address? Are you able to open a Telnet session to it?  What are the contents of the AutoScript file you are using? Do you see the ABCDEFGH scroll on the oppo’s character display? 

Link to comment
8 hours ago, tmtomh said:

 

In my experience the Oppos don't display ABCDEFGH

 

Mine does. It’s a 103 model. Of course it would not if I didn’t have the scrolling display line in my AutoScript as a confirmation that the script launched successfully. 

 

8 hours ago, tmtomh said:

 you don't need to be able to open a telnet session for it to work.

 

True, but as it’s been mentioned before, having the telnet session capability is an excellent troubleshooting resource; especially for someone new to the process and attempting to work through the myriad missteps that can break the chain and prevent things from working. 

 

For this reason, even though I always rip rip by the server method I still keep the telnet daemon running via my AutoScript just in case I want to open a session and look at or do something.

 

3 hours ago, haggis999 said:

It always works for me if I'm using the correct IP address.

 

Yes it’s great when it works in a turnkey fashion, but clearly there is something (probably a trivial something) that is preventing it from working at this point for @David B..  This is why I broke open a small piñata of general questions (some of which may not be applicable if he is not using a telnet enabled AutoScript) as a precursor to a more refined set of questions and suggestions in order to help troubleshoot. 

 

Based on the information we have so far we don’t even know if he is able to even ping the oppo from his computer. Nor do we know if the AutoScript is even being launched by the player. Assuming the former are affirmative, is sacd_extract running and listening on 2002? We certainly don’t know that at this point, although I am suspecting it is not. If not why not? An error in the script? The USB drive mounting under a device other than sda1 that the heretofore AutoScript cannot find? Etc. etc..

Link to comment
1 minute ago, diecaster said:

Okay, there is a reason AccurateRip exists in the CD world. Just because a player can rip does not mean you are assured to get an accurate rip. Without something like an AccurateRip database to compare against, it's pretty clear that a higher quality mechanism will result in better chance to get a bit perfect rip.

 

Someone smarter than me (and there are many) will need to explain the underlying reason, but AFAIK that which is true for Redbook CDs is not the case for SACDs. It is my understanding that SACD rips are bit perfect, ie the checksum is repeatable. At least insofar as full ISO image rips are concerned. 

Link to comment
  • 2 months later...
5 hours ago, Chiefbrodie said:

Wow thank you for that info once again I'll first try this evening changing the directory and see if that's where I've fallen down but reading what you just listed that sounds on paper relatively simple although creating text doc files etc is very alien to as I've never needed to do anything like that I restore furniture for a living so only ever use my pc for leisure but just googled it and it seems straight forward so once again a big thank you. Will feed back later 

When you CD to your S drive root folder, S:\ *and* if that is in fact where your copy of sacd_extract.exe is, then that should put to bed your *final* issue. That is you and Elvis ? will be strolling down the aisle in K-Mart reminiscing about all those great times in Vegas you never had. 

 

But alas the blue light special will not be there for you unless and until you go back to square one and work on identifying and fixing the one or two or more problems with the prerequisite steps along the way. 

 

I think you you really need to forget about ? for the time being and focus on being able to answer three questions in the affirmative:

 

1. Are you able to successfully ping your player using the IP address your player is reporting in its settings?

 

2. Have you verified that the AutoScript file is launching? (for example by using a script with a tray opening line and noting that the tray in fact opens.)

 

3. Are you able to launch your player’s Telnet daemon via an AutoScript file designed to do so?

 

Until you work through these things, everything you’re doing on your computer with sacd_extract and Windows command scripts is as pointless as trying to convince Elvis ? that if he lets you wear his fancy jacket, the Blue Light Special will magically appear. This is not to say it wouldn’t be really cool to take a ?? with ? while you’re wearing his jacket ?. It’s just that it’s a futile exercise at this point.  

Link to comment
6 hours ago, Chiefbrodie said:

e.g.: .\sacd_extract -i 192.342.1.217:2002

@Chiefbrodie, once you have navigated to your S folder, using the commands that have been provided in unambiguous detail by @greynolds (above) there is no need to include the ".\" portion of your command above.  It would not be incorrect per se; but it only says "look for the file in the place I'm already at", which is what would happen anyway.  OTOH it is just too more characters of an opportunity to introduce a typo or a space that doesn't belong or whatever.

 

Link to comment
6 hours ago, Chiefbrodie said:

So assuming I get the directory to the S folder where in that path would the S go? Or how should it look. 

The more I read your post the more it makes sense very simple to follow thank you. 

Assuming you get the directory to the S folder, then what S are you referring to?  Do you mean the S that will at that point appear as a portion of the command prompt?  For example:

 

C:\S>. (in the case where your S folder is at the root level of your C drive)

 

or alternatively

 

C:\Users\Daniel\S> (in the case where your S folder is a subfolder of your home folder)

 

In the former case it would look exactly like @greynolds presented to you a few posts back.  In the latter case it would look like the second example above.

Link to comment
6 hours ago, Chiefbrodie said:

OK since I'm on a major learning curve here can you give details on your procedure using iso2dsd as I have tried that method also and equally failed so it can't harm to have various options. Many thanks. 

 

@Chiefbrodie, to reiterate my observation of a few days ago:  your fundamental overarching problem is that you are working the problem from the wrong end.  No matter how accomplished you become at navigating Windows folders at the command prompt or typing in sacd_extract commands or learning how to create a command script to automate that, you will never EVER rip an SACD using the server method if the remote, i.e. player side, sacd_extract Linux program is not running and listing on port 2002.  Will not happen.

 

One of the pics you posted the other day was of the Sonore ISO2DSD GUI showing fields that appeared to be correctly populated.  That tells me a few things, mostly good but not exclusively so:

 

1.  You already know how to navigate to your S folder (or at least wherever your DSD2ISO GUI program is located)

2. You already know how to launch the GUI and fill in the correct information and select the options you desire.

and even more better ...

3. It appears that the ISO2DSD program is able to find and launch the sacd_extract.exe program. Presumably because they are colocated as they would need to be on the Mac.  Caveat: I have never used it on Windows and that part of the implementation may be different.

 

So basically, you already know how to use ISO2DSD, which is nothing more than a fancy GUI that launches sacd_extract with all the correct command line options done for you. Voila!  Okay so I'm gonna go out on a limb here and suggest you might be much happier using the GUI than the more intimidating command line approach.

 

Moving on to the bad part ...

 

4. Based on the error message you see in the bottom half of your ISO2DSD window, sacd_extract.exe, once launched by the GUI after you click on the Execute button, is unable to "talk to" the remote sacd_extract server running on your player.

 

Why would this be?  No telling.  But let's say you're trying to talk to Elvis whom you believe to be in the next room but he's not answering.  Why isn't he answering?  There are a few plausible explanations.

 

A) He might not be listing

B) He might not actually be in the next room (or even in the building)

C) He might be comatose.  But let's just call that a variation of (A)

D) He might be jerking your chain and he'll eventually tire of that game and respond if you repeatedly shout "HEY ELVIS" for long enough.

 

Well, reasonable people often disagree on whether or not Elvis is in the building, but most people would agree that fixating on trying to solve the problem as if (D) were the issue is unlikely to change the outcome.

 

Circling back to SACD ripping: 

You can go on for days, weeks or months asking people to provide more and more detailed instructions on how to type things on your computer that assume you have everything squared away on the player side.  But if you don't have everything full green check marked on the player end, and if you are unwilling to follow the player side troubleshooting techniques and procedures that have been present ad nauseam throughout this forum, e.g. Telnet, then it's all just whistling in the dark.

Link to comment
3 hours ago, Phthalocyanine said:

It's great that we now have some many choices in models and methods.

 

Yes!  1️⃣

 

Isn’t it awesome that we can now wax philosophically wrt to the myriad permutations of methods and hardware choices when a scant few years ago I was lamenting my lack of a venerable PS3? ?  

Link to comment

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now



×
×
  • Create New...