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

[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. ??‍♂️ 

[Phthalocyanine]

Quote

I got these "File exists" messages with and without the insmod in the AutoScript.

After those two error messages, do you get the same command line results for your rips like what I just posted?

[Phthalocyanine]

2 hours ago, Phthalocyanine said:

I don’t understand why one needs the -i 127.0.0.1:2002 for local ripping.

I simply use

./sacd_extract_160 –I

and get the same result.

Quote

That's true. Thank you for the tip

 

I wonder if you will get those 2 error messages with my shorter command version.

[lucretius]

On 3/8/2018 at 2:28 PM, MikeyFresh said:

 

Additionally, the Cambridge CXU is also known to work.

 

Cambridge Audio has already come out with the CXU version 2.  Does anyone know if this would work?

[klassikmann]

9 hours ago, Phthalocyanine said:

 

I wonder if you will get those 2 error messages with my shorter command version.

I used your shorter commands.

[Phthalocyanine]

Quote

I used your shorter commands.

And did you still get those error messages?

[klassikmann]

31 minutes ago, Phthalocyanine said:

And did you still get those error messages?

Yes. Two observations:

1. The error messages

    mknod: /dev/sacd_read: File exists
    insmod: can't insert '/tmp/filerFFmzY': File exists

are refering to non-existing files neither the device-file nor the temp-file are present.

2. If I start the second "./sacd_extract_160 -I" there are no more such messages.

 

But I do not longer brood over the messages.

[JediJoker]

15 hours ago, lucretius said:

 

Cambridge Audio has already come out with the CXU version 2.  Does anyone know if this would work?

No. Like the CXU before it was based on Oppo BDP-103D architecture, the CXUHD is based on Oppo UDP-203 architecture.

[Wanderlust]

19 hours ago, lucretius said:

 

Cambridge Audio has already come out with the CXU version 2.  Does anyone know if this would work?

Lucretius, I have an Oppo 103d up for grabs. 

 

Please let me know if you are interested. 

[kennyb123]

Last night I was able to rip 4 SACDs with a Sony BDP-S590 using the telnet method.  A huge thanks to @Dick Darlington, @Phthalocyanine, @klassikmann and others for their very helpful posts.  I struggled a bit due to by own cluelessness.  But also I think what might have been what got me over the hump was powering on the player with the USB stick in place.  I’ll have to repeat this to confirm - I was just so excited to make a telnet connection, that I left everything as is and went on to rip 4 discs, one after the other, simply toggling that setting after inserting each disc.

 

A few years back I spent about $300 for a PS3 to rip SACDs.  I got my money’s worth out of it before it finally died.  I was planning to replace it with an Oppo 103 eventually.  My wallet sure is happier to have only forked out $55 for a Sony that can do this instead.  Again, a tremendous thanks to those of you who were so generous with sharing your findings.

[kennyb123]

On 3/9/2018 at 1:35 PM, Phthalocyanine said:

 

 

I don’t understand why one needs the -i 127.0.0.1:2002 for local ripping.

 

I simply use

 

./sacd_extract_160 –I

and get the same result.

 

 

I never get any such error messages.  A typical rip looks like the following on the command line.  (Perhaps you are getting those error messages because you are not including CLI(CLI_exec insmod /lib/modules/2.6.35/BDP/splitter.ko).)
 

sony-player login: root

~ # cd /mnt/sda1/AutoScriptSACD/

/mnt/sda1/AutoScriptSACD # ./sacd_extract_160 -I

[0]: convert_string(): Conversion not supported. Charsets: ISO646-JP -> UTF-8

[0]: convert_string(): Conversion not supported. Charsets: ISO646-JP -> UTF-8

[0]: convert_string(): Conversion not supported. Charsets: ISO646-JP -> UTF-8

[0]: convert_string(): Conversion not supported. Charsets: ISO646-JP -> UTF-8

[0]: convert_string(): Conversion not supported. Charsets: ISO646-JP -> UTF-8

[0]: convert_string(): Conversion not supported. Charsets: ISO646-JP -> UTF-8

[0]: convert_string(): Conversion not supported. Charsets: ISO646-JP -> UTF-8

Processing [Columbia Symphony Orchestra, Bruno Walter - Beethoven Symphony No.6 in F Major, Op.68 Pastorale.iso] (1/1)..

Completed: 100% (1676.5MB), Total: 100% (1676.5MB) at 2.97MB/sec

 

Exactly the result I got.

[threehugga]

On 1/1/2018 at 12:42 PM, Peter M said:

 

That's not my experience.  I rip from my Pioneer 160 using sacd_extract.  I don't use ISO2DSD at all in the ripping process.  My workflow is -

sacd_extract to rip ISO

sacd_extract to convert to DSF

dBpoweramp to convert to FLAC

 

It seems a lot of people here are using Sonore ISO2DSD to make DSF directly from their player, is this correct? You workflow seems better. I have been having problems with Sonore's program creating bad files (skips, distorts), freezing on a track mid album so it cant finish the dsf, and the dsf are all about 10kb bigger respectively than the same file as a dsf from sacd_extract.

 

Can anyone confirm that sonore ISO2DSD is bugridden crapware with the problems I have described? Also, can anyone tell me what the extra 10kb in every file is for? and finally, can anyone vouch for the sacd_extract software, and last, is there anyway to verify that the dsf file generated is bit perfect to the source iso?

[andy1249]

3 hours ago, threehugga said:

 

It seems a lot of people here are using Sonore ISO2DSD to make DSF directly from their player, is this correct? You workflow seems better. I have been having problems with Sonore's program creating bad files (skips, distorts), freezing on a track mid album so it cant finish the dsf, and the dsf are all about 10kb bigger respectively than the same file as a dsf from sacd_extract.

 

Can anyone confirm that sonore ISO2DSD is bugridden crapware with the problems I have described? Also, can anyone tell me what the extra 10kb in every file is for? and finally, can anyone vouch for the sacd_extract software, and last, is there anyway to verify that the dsf file generated is bit perfect to the source iso?

 

I am using an Oppo 105D

I have 800 + SACD's

I have been using ISO2DSD for years and have no problems similar to yours

I have also used SACD extract

ISO's from both methods always turn out identical for me.

 

I have also , and with the same title , burned the ISO to DVD R and ripped from the DVD R and the resulting ISO is once again , identical to the ISO ripped from the original SACD , this gives some level of confidence in the rip being bit perfect as it is reproducable.

 

Notes.

I use Jriver with Jremote  to send/play back my ISO's and DSF files.

All of my destination players are non decimating DSD capable playback devices with Sabre DACs

They are Oppo 105D , Auralic Aries Mini , and Yamaha 3060 receiver.

 

I do not convert to flac , this is decimation and is a problematic and lossy process , I see no point is doing this.

 

If you are getting skips , distorts , look at your playback chain , I have had similar problems to yours in the past but can confirm that in my case the culprit was the playback software and methods I was using before Jriver.

 

There is nothing inherently wrong with the way ISO2DSD rips the discs , Ive been following this thread since it started , and as far as I can see , there are many users using ISO2DSD without any problems.

[superstar19]

5 hours ago, threehugga said:

 

It seems a lot of people here are using Sonore ISO2DSD to make DSF directly from their player, is this correct? You workflow seems better. I have been having problems with Sonore's program creating bad files (skips, distorts), freezing on a track mid album so it cant finish the dsf, and the dsf are all about 10kb bigger respectively than the same file as a dsf from sacd_extract.

 

Can anyone confirm that sonore ISO2DSD is bugridden crapware with the problems I have described? Also, can anyone tell me what the extra 10kb in every file is for? and finally, can anyone vouch for the sacd_extract software, and last, is there anyway to verify that the dsf file generated is bit perfect to the source iso?

The only time I've had issues with the software was when I was attempting to rip the multi-channel layer from some Bob Dylan SACDs that I had checked out of the local library. It would freeze up right at about 99%. The discs didn't look damaged or anything so I don't know if it was something inherent with the encoding of those particular discs or there was actual damage on the disc. But other than that all of my rips with the Sonore software have been fine.

[ted_b]

I've used Jesus's ISO2DSD for years, with no problems (Windows).  That being said, I mostly use Bogi's workflow now, simply because it does not require as much interaction.  Just a right click on the ISO file in Windows Explorer.

 

 

[Kal Rubinson]

7 hours ago, threehugga said:

 

It seems a lot of people here are using Sonore ISO2DSD to make DSF directly from their player, is this correct? You workflow seems better. I have been having problems with Sonore's program creating bad files (skips, distorts), freezing on a track mid album so it cant finish the dsf, and the dsf are all about 10kb bigger respectively than the same file as a dsf from sacd_extract.

 

Can anyone confirm that sonore ISO2DSD is bugridden crapware with the problems I have described? Also, can anyone tell me what the extra 10kb in every file is for? and finally, can anyone vouch for the sacd_extract software, and last, is there anyway to verify that the dsf file generated is bit perfect to the source iso?

Do you realize that the Sonore ISO2DSD is merely a convenient GUI for sacd_extract and that, functionally, they are the same?  There should never be any difference in the results between using ISO2DSD and using sacd_extract with a command-line script as long as the same version of sacd_extract is employed.  The only difference, imho, is convenience.

 

 

[Stampie]

On 09/03/2018 at 6:24 PM, klassikmann said:

Experiences with Sony BDP-S490

 

Scenario 2: No network connection i.e. no telnet
Contents of AutoScript:
#MTKAT 0.xx script
CLI(CLI_exec echo root::0:0:root,,,:/root:/bin/sh >/etc/passwd)
SLEEPMS(3000)
CLI(CLI_app.vfdmg.b clear_msg)
CLI(CLI_app.vfdmg.b scroll_msg start)
SLEEPMS(5000)
CLI(CLI_exec cp /mnt/sda1/AutoScript/sacd_extract_160 /)
CLI(CLI_exec insmod /lib/modules/2.6.35/BDP/splitter.ko)
CLI(CLI_exec /sacd_extract_160 -S &)
CLI(CLI_drv.ir.rx.sq 0xaf000)
CLI(CLI_exec /bin/sh /mnt/sda1/AutoScript/mysh.sh)
CLI(CLI_drv.ir.rx.sq 0xaf000)

 

Explanation:
This script is very similar to the first. At the end the drawer opens, you insert the SACD, a shell-script (mysh.sh) to rip the SACD will be executed, and finally the drawer opens. The resulting ISO can be found in the AutoScript directory.

 

Contents of mysh.sh:
sleep 50
cd /mnt/sda1/AutoScript
./sacd_extract_160 -I -i 127.0.0.1:2002

 

Explanation:
Wait for 50 seconds, time enough to change the music settings (If anybody is aware about a solution to change the music settings inside AutoScript, please let me know) as described already. Then the client will be executed. 127.0.0.1 is the IP address of the localhost, which is a valid IP address even no network connection is available.

 

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.

 

Now we have my requested stand-alone scenario.

 

 

 

I can confirm another successful rip using scenario 2 on Sony BDP-S490. I checked the ISO against a rip done with Oppo 105 and can confirm they were identical

 

Many thanks

Nick

 

[threehugga]

Hi Kal,

I understand your arguement but I cannot understand why I would be unable to complete a DSF from ISO with sonore but it processes fine with sacd_extract. I can make a demonstration video and upload it as proof if you dont believe me.

Furthermore, all sonore outputs are about 8kb larger files than from sacd_extract. Last, sonore outputs corrupted files about 1% of my attempts. Truely bad software. Same results on different machines. Rather than your claim which is unsubstantiated, I would like a response from sonore on how I can debug and troubleshoot the problems with their software.

 

Thanks in advance

[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. 

[ted_b]

It’s just a GUI front end, regardless of OS

[dtblair]

Tried to get the Sony BDP-S790 working but never could get it to unload the disk.  Picked up a BDP-S590 and it's working great.

 

Two issues: 

1) iso2dsd_PC_v7 cleaves off last seconds of each file when converted to dsd.  iso plays fine in JRiver all the way to the end of each song.

2) Smetana Má vlast  fails due to the character over the "a" in the file name.  Any way to get around this?

 

[threehugga]

1 hour ago, ted_b said:

It’s just a GUI front end, regardless of OS

This is absolutely untrue. the sonore ISO2DSD gui fails to process an ISO on track 3 of 10, where the sacd_extract completes the process through all 10 without problem.

 

sonore ISO2DSD cannot read certain asian characters (im not speaking in reference to the first problem above, this is a different album it cannot read)

 

and sonore ISO2DSD outputs have many differences in the code than the files output from sacd_extract command line (file sizes are 8-10kb different on every track) Check it yourself. Get the one ISO, use sonore, then use sacd_extract. the files are not the same.

 

Version 7 on WINDOWS

sacd_extract 0.3.8

 

[ted_b]

Huh?  What are you debating?  You even call it a GUI.  That was merely my point.  It is a front end interface to sacd_extract.  You have uncovered bugs or issues with the interface, ok.  What's your point?  That Jesus and team are plotting to destroy your data?  Hell, I've used various versions of command line sacd_extract to extrcat several different SACD ISOs, as one would hiccup on certain foreign characters, path names, etc and require us to go back a version or two.  And that was back when we had no GUI (or Bogi workflow).  Same was true for various versions of the PS3 ripper, etc.  It's all software, it's all full of bugs, always.  Welcome to computer audio.

[threehugga]

2 hours ago, ted_b said:

It's all software, it's all full of bugs, always.  Welcome to computer audio.

I'm not debating, I'm commenting here and in the support area for sonore, that the data sonore ISO2DSD outputs is different by approximately 10kb in each file than the data created from sacd_extract. IF sonore ISO2DSD was "just a GUI" then the data output would be identical; it isnt. Sonore ISO2DSD modifies the output file, and nobody can say with any certainty what they do to it.

Since so many people are trying to push the narrative that its "just a GUI" which it demonstrably is not, I have to assume the worst; possibly a front company pushing malware in our data. The price you pay for "the sound having to be in concert with the music". Sounds nice but I have no clue what that means. All I can say for sure is sonore is definately not just a GUI of sacd_extract and the files it creates are not identical and nobody can argue with that. If you want what everyone claims sonore is creating, you MUST not use ISO2DSD because its a sham. The only true platform that has been audited is the sacd_extract software. If you use sonore you are accepting that all of its files are tampered with.

[Phthalocyanine]

@dtblair

Glad you got a S590 to work!

 

Quote

2) Smetana Má vlast  fails due to the character over the "a" in the file name.  Any way to get around this?

 

Using telnet and command line and local ripping:

 

PROCEDURE FOR ACCENTED CHARACTERS
If there are accented characters in the ISO name such as ö, ü, é, ñ, the PuTTY window might display "invalid argument" and ripping will not start. Here is a workaround:
• Re-paste the command ./sacd_extract_160 –I
• Add one space after –I and type two straight quotation marks
• Copy or type the ISO (album) name directly in between the quotation marks
• Delete the accented characters and type non-accented characters into the ISO name
• Hit Enter to start the SACD ripping process