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

[MadDane]

On another note, the Pioneer BDP-80FD that I tried to use at first was frought  with problems, and so I ultimately returned it to the ebayer I purchased it from.

 

I just received the new remote control for it that I had ordered from Japan. 

It's brand spanking new if anyone wants/needs it.

 

I'll let it go for 1/4 of what I paid plus shipping.  $5 whopping dollars.

 

Let me know,  I have no use for it. 

[BluRay444]

16 hours ago, Phthalocyanine said:

Fair enough. 

 

However for those who may be neurotic about not putting any wear and tear they don't absolutely have to on their $800+ Oppo 103, it might be useful to know that SACD-Rs can be ripped to .iso with any cheap DVD drive and commonly available freeware like Imgburn.

...I did state in my original post on this subject that I only had 2 CDR's.... but how much 'wear and tear' on a tank of a Bluray Player like the Oppo makes you neurotic? I'd be worried more about power surges than ripping a few, or even a few hundred CR's on the Oppo.

[Nexus3]

On 9/8/2018 at 10:19 PM, mindset said:

To users of sacd_extract using the server method:

 

I have been working on improving the sacd_extract client program from the currently inactive original sacd-ripper repository past few months.  I thought I would share that in case someone is interested.  Here is the git repository: https://github.com/setmind/sacd-ripper/  (Sorry, you need to compile the code to use it).

 

In addition to performance improvement and bug fixes, I have added features like concurrent extraction of ISO and DSF/DSDIFF in a single scan of a disc, padding-less DSF generation for some players that cannot handle DSF tail padding properly, extraction of multi-channel and single-channel tracks in one shot, and addition of more ID3v2 tags from TOC to DSF.  Details with compilation instruction are described in https://github.com/setmind/sacd-ripper/blob/master/readme.rst and performance comparison with the original is here https://github.com/setmind/sacd-ripper/wiki

 

It seems to work fine on Linux and Windows, but unfortunately is unverified for macOS since I do not have a Mac.  If anybody has a chance to try this on Mac, please report back.  I welcome any feedback.

 

Thanks.

 

Hello mindset,

 

I was very eager to test your DST decompression boost but got stuck somehow.

Compiling your sources (on Ubuntu x64) went fine, but upon finishing extraction of the first track sacd-extract always runs into the following error:

 

Exporting CUE sheet [Dire Straits - Brothers In Arms - 20th Anniversary Edition.cue] 
 
Processing [Dire Straits - Brothers In Arms - 20th Anniversary Edition/01 - Dire Straits - So Far Away.dsf] 
(1/9).. 
Completed: 100% (219,9MB), Total: 9% (219,9MB) at 2,36MB/sec

sacd_extract: /.../sacd-ripper/libs/libdstdec/buffer_pool.c:138: buffer_pool_free: Assertion »count == pool->made« not satisfied.

 

 

On a playback note:

Has anyone laid hands on this interesting SACD plugin for Kodi ? ISO playback sounds nice, but SACD-R support would be the ultimate goal.

[Phthalocyanine]

1 hour ago, Nexus3 said:

Has anyone laid hands on this interesting SACD plugin for Kodi ?

Is there a compiled version of this for osmc on raspberry pi 3?

I'd love to try it out.

[mindset]

3 hours ago, Nexus3 said:

 

Compiling your sources (on Ubuntu x64) went fine, but upon finishing extraction of the first track sacd-extract always runs into the following error:

 

Exporting CUE sheet [Dire Straits - Brothers In Arms - 20th Anniversary Edition.cue] 
 
Processing [Dire Straits - Brothers In Arms - 20th Anniversary Edition/01 - Dire Straits - So Far Away.dsf] 
(1/9).. 
Completed: 100% (219,9MB), Total: 9% (219,9MB) at 2,36MB/sec

sacd_extract: /.../sacd-ripper/libs/libdstdec/buffer_pool.c:138: buffer_pool_free: Assertion »count == pool->made« not satisfied.

 

Interesting...  I am also using Ubuntu (64bit) for development, but have never encountered that over many different discs.  Would you be able to share the exact command you used?

[mindset]

5 hours ago, Nexus3 said:

 

Hello mindset,

 

I was very eager to test your DST decompression boost but got stuck somehow.

Compiling your sources (on Ubuntu x64) went fine, but upon finishing extraction of the first track sacd-extract always runs into the following error:

 

Exporting CUE sheet [Dire Straits - Brothers In Arms - 20th Anniversary Edition.cue] 
 
Processing [Dire Straits - Brothers In Arms - 20th Anniversary Edition/01 - Dire Straits - So Far Away.dsf] 
(1/9).. 
Completed: 100% (219,9MB), Total: 9% (219,9MB) at 2,36MB/sec

sacd_extract: /.../sacd-ripper/libs/libdstdec/buffer_pool.c:138: buffer_pool_free: Assertion »count == pool->made« not satisfied.

 

Aren't you using one of the old commits from github?  With the latest code, there is actually no way to get a cue sheet and dsf in one shot like your output is showing, and there was a bug in thread handling which terminates the process after the first track extraction.

[Dick Darlington]

How I Spent My Summer Vacation, Found Love and Ripped My Very First SACD:  PART 1 of <there is no telling>

My new Pinchas Zukerman / English Chamber Orchestra Vivaldi: The Four Seasons SACD arrived in the post yesterday ? and I decided to combine the ISO ripping process with a demonstrative experiment?, primarily for the benefit of newcomers, but also with the hope of presenting a simple validated near-universal AutoScript proven to work with both the Sony and Oppo player classes.

 

For the noobs, I trust this will demonstrate how simple how simple this process actually is with a properly composed AutoScript and strict attention to tried and true procedures.

 

Also for the noobs, I hope to demonstrate that incorporating optional Telnet access into your script even if you plan to use the server method exclusively:

• Costs you absolutely nothing.
• Will not in any way shape or form prevent your script from working.
• Will ensure that the option to look at what’s going on inside the player will always be there when/if the need arises.
• Will be a troubleshooting timesaver and help those trying to help you figure out what you are doing wrong if you can’t get the process working. (And make no mistake: if you face plant on your initial attempts, it’s not the script; it’s not telnet; it’s you.  There are a dozen show stopper things you could do wrong, and if you use this script without success then you have tripped over at least one of them.  Better to embrace that and find the problem quickly than to spin your wheels whilst generating mis-information that will confuse those that will follow.)

So if you find yourself confounded and asking for help, think of using a Telnet enabled script as a courtesy to those volunteering their time to help get you up and ripping.  Just a thought. ?

 

If nothing else other than to rip my new SACD, I wish to establish as fact that just because there are myriad scripts (not to mention posts) that treat Telnet access and the so-called "server method" as mutually exclusive doesn't mean it has to be that way and thus unnecessarily complicated.

 

To this end, and to present with absolute confidence a near-universal Telnet+Server Method AutoScript for use with either the Sony or Oppo players I decided to set aside my trusty tried and true AutoScript USB drive and start from scratch as if I was going through the process for the very first time. "Like a Virgin" { Dick goes off the rails again.  This time channeling his inner Madonna. }

 

Again, for noobs please know that there are many variations to what I’m presenting here that will also work.  For instance I could have used NTFS instead of FAT32.  I chose the former simply because it’s more convenient in my case since my primary computer is a Mac.

 

In other words I am NOT claiming things must be done exactly this way.  I AM claiming that if you use this script in the manner I just did (that is with a properly prepared USB drive and a properly configured computer on the same network with your Sony S590 player) it WILL work for you.

 

If you do this and it does not work, then you have done something wrong because a) it works and b) it's damn easy. <hmmm I wonder if this is a good time to plug my online real estate wealth classes? ?>.

 

The following script and steps worked flawlessly for me on the first go with my S590.  And without a hitch on my first pass when I repeated it (with a few player specific changes) using my Oppo 103.

 

So without further adieu, here is how I started from scratch and ripped my new SACD earlier today; first using my Sony S590 and then again using my Oppo 103:  (note that the procedure for the Oppo varied slightly from the following Sony procedure due to player differences but the script used was identical save for the “_160” needing to be removed from lines 9 and 10 when used with the Oppo.

 

1. I grabbed a random 8 GB USB stick and reinitialized and formatted it as a Master Boot Record type disk with a single FAT32 volume in accordance with the USB drive preparation guidelines that have been provided many times over on this thread.
2. On my Windows computer (see note below that I may or may not remember to add regarding why I chose to use Windows instead of my Mac for this step) I created a new folder named “AutoScript”.
3. I placed a copy of the Linux “sacd_extract” and “sacd_extract_160” binary files into the AutoScript folder to support ripping on the Oppo and the Sony players respectively.
4. I created a new, empty text file named “AutoScript.TSS” ensuring that it did NOT contain the default “.txt” extension, hidden or otherwise, and placed it inside the the AutoScript folder alongside the two Linux programs.
5. Using Notepad, I opened AutoScript.TSS for editing and entered the following lines of script.  FWIW I actually cut and pasted the non-commented out lines directly from my own highly annotated universal AutoScript file that up until yesterday I had made available to the community in my DropBox folder. (see note below that I may or may not remember to add regarding why having my annotated universal AutoScript file publicly available was a monumentally bad idea and why I have removed it from the DropBox folder.). The exact, character for character contents of my freshly composed AutoScript.TSS file are as follows:
6. Taking a moment to pause and inspect my handiwork, I took note of the fact that some lines, such as the ones affecting the player’s character display and the final line that opens the tray are in no way required for the ripping process to work.  I just like them there and they do serve a purpose, albeit nonessential.
7. I took a moment to contemplate how necessary if at all the SLEEPMS lines are.  I resolved to save that experiment for another day.
8. I felt a pang of chagrin at not remembering who the contributor is that provided a more robust version of the “CLI_exec cp /mnt/sda1…” line that eliminates the point of failure of the mount point ending up different than “sda1” so that I could PM him instead of searching half the thread to find it and being too lazy to do so.  Sigh.

{ Note to noobs: steps 6 - 8 above are not actually required }

9. I copied my shiny new AutoScript folder containing AutoScript.TSS and the sacd_extract binaries to the root folder of my freshly formatted USB drive and removed it from the computer.
10. I unplugged the player from AC power and momentarily plugged it back in. (This was to ensure that any previously running Telnet and/or sacd_extract_160 processes were terminated AND MOST IMPORTANTLY to ensure the USB disk would mount in the expected /mnt/sda1 location. Hence step 8 above.)
11. I powered up my Sony player and confirmed that “Quick Start Mode” was set to ON (available in Setup->System Settings) and confirmed that the IP address was what I believed it to be (available in Setup->Internet Settings->View Network Status).
12. I opened a macOS terminal window on my Mac and employed the ping command to confirm network connectivity to the player at the IP address verified earlier.
13. I penetrated the player’s slot (specifically the front slot) with my virgin USB stick and hoped for a response.
14. Within a few seconds I observed “0000” on the character display (pronounced oh oh oh oh) followed soon after with the tray coming out and the display changing to “home”.
15. In order to assess that all was on track I used netcat (the “nc” command on my Mac to verify that the player was indeed listening attentively on both the Telnet and sacd_extract ports; ports 23 and 2002 respectively. (This would generally be a troubleshooting step and not normally performed otherwise BTW.)  The macOS commands I used (specific to my player’s IP address of course) were:

nc player_ip_address -vz 23

and

nc player_ip_address -vz 2002

 

The results of both nc queries were positive confirming that both Telnet and sacd_extract_160 were running on the player.

16. I opened a Telnet session on the player from my Mac using the command:  telnet 10.10.42.69.  When prompted by the player I entered the username “root” sans quotes, hit Enter, and I was in like Flynn.
17. Just for grins I entered the command: “ps” sans quotes to list all of the currently running processes and indeed sacd_extract_160 running in server mode was listed.  Winning!  (Note that at this point had I wanted to rip locally to the USB drive I could have simply killed the running sacd_extract_160 process and proceeded in accordance with the S590 Guide.
18. I laid my new SACD on the now open tray and … IMPORTANT … PAY ATTENTION … I WON’T SAY IT AGAIN … hit the power ON/OFF button on the player which in turn closed the tray and put the player into a sleep state.
19. Back on my Mac I launched the Sonore ISO2DSD GUI and selected Server Input, Print, and Raw ISO Output Mode.
20. I entered the player’s IP address appended with 2002 into the IP Address | Port field.
21. I stood up and turned around thrice clockwise and thrice counterclockwise and returned to my seat.  (Optional but recommended if you’ve been sitting for a while.)
22. I clicked on the ISO2DSD Execute button and waited for what felt like an hour but was in fact only 16 seconds and voila! The ISO2DSD output screen populated with disk and track information and the ripping process commenced.  A few minutes latter the title’s ISO image was on my Mac’s hard drive and ready for the next step in my workflow.
23. Pretending I wanted to re-rip my Aerosmith Toys in the Attic SACD, I opened the tray with the Open/Close button on the player; swapped disks and hit Power ON/OFF.  Allowing a few seconds after the tray closed I hit “Execute” in ISO2DSD again to initiate the second rip.

There is a slight caveat regarding step 23.  Powering the player on and off to rip multiple disk in one go should probably not be done while the USB stick remains inserted.  This is because the AutoScript will execute again with each cycle and in doing so launch another instance of sacd_extract.  That didn't present a problem on my second disk, but I expect the player would eventually become low on resources after some number of iterations.

 

Next Up:  The Oppo Experience:  A few minor differences and a touch of refined elegance.

 

Cheers! ?

[Dick Darlington]

Just now, Dick Darlington said:

The exact, character for character contents of my freshly composed AutoScript.TSS file are as follows:

 

Quite annoying but CloudFlare wouldn't let me post the script code in character format for fear that I was trying to hack the site.  This image will have to do.  Try as I might I could not make it any larger unfortunately. ...

[Nexus3]

19 hours ago, mindset said:

Aren't you using one of the old commits from github?  With the latest code, there is actually no way to get a cue sheet and dsf in one shot like your output is showing, and there was a bug in thread handling which terminates the process after the first track extraction.

 

@mindset

I stand corrected, your sacd_extract is indeed working but is incompatible with the java GUI [iso2dsd_gui.jar] in certain circumstances.

 

DST to DSD conversion errors:

sacd_extract: /.../sacd-ripper/libs/libdstdec/buffer_pool.c:138: buffer_pool_free: Assertion »count == pool->made« not satisfied.

or

sacd_extract: /.../sacd-ripper/libs/libdstdec/dst_decoder.c:307: write_thread: Assertion »dst_decoder->decode_head == NULL && peek_lock(dst_decoder->decode_have) == 0« not satisfied.

 

If the CLI is used, the output is valid:

 

sacd_extract -i 192.168.178.53:2002 -2 -c -s -t 1

sacd_extract -i 192.168.178.53:2002 -m -c -p -t 2

 

@ALL

 

If you aim for ISO output or just a plain DST extraction of the tracks (without a decompression to raw DSD), you can use the GUI with minset's sacd_extract.

 

If you desire uncompressed DSD files as output you should avoid the GUI and use the CLI directly. The speed gains are considerable!

[mindset]

27 minutes ago, Nexus3 said:

 

@mindset

I stand corrected, your sacd_extract is indeed working but is incompatible with the java GUI [iso2dsd_gui.jar] in certain circumstances.

I see.  I haven't tried iso2dsd (not a big fan of it).   Will try to reproduce the problem.  It's probably easy to fix.

[Nexus3]

For some reason I am unable to edit my former post. ?

 

I was mislead by the GUI, yet again ?

 

DST and ISO extraction finishes without errors, but the results do not play. Feeded the files to DeaDBeeF and foobar2000 1.4 (through Wine), to no avail.

 

 

[mindset]

4 minutes ago, Nexus3 said:

DST and ISO extraction finishes without errors, but the results do not play. Feeded the files to DeaDBeeF and foobar2000 1.4 (through Wine), to no avail.

Are you sure that you are using the latest code from github?  Some of the older commits (before my announcement here) had that problem.

[Nexus3]

39 minutes ago, mindset said:

Are you sure that you are using the latest code from github?  Some of the older commits (before my announcement here) had that problem.

 

I surely hope so, here are the MD5sums from /sacd-ripper/libs/libdstdec/ :

 

FileName	MD5 HashValue				FileSize
buffer_pool.c	12A90BD0344CAF6CBEBD34FE37B3F544	4,04 KiB
buffer_pool.h	856D9528D1BD05F87AA8C8F48E7AAEE2	3,33 KiB
ccp_calc.c	25B1B2D50354DA869DCDCFD02234D281	5,06 KiB
ccp_calc.h	BE4781DEB9190414174014671B9D5449	2,41 KiB
conststr.h	03BBD4D776AE5E40F7F3F3850E64ED14	6,58 KiB
dst_ac.c	551E582FDE6AF7D41786BE2667C10219	7,31 KiB
dst_ac.h	CA547BE4985B1864130AABAD761919FD	2,75 KiB
dst_data.c	977A8C19ECB4A3B2B06E2FF20106A875	14,25 KiB
dst_data.h	AD956EACFBB848371B20CCA7A1D82228	3,46 KiB
dst_decoder.c	27A71B5B85A669A8536BF6790D8FB2A3	13,46 KiB
dst_decoder.h	9BA16B26D0CAA684A69F4573A164E25C	1,47 KiB
dst_fram.c	18D58AA6EFD161BFA033D34EFDC73438	17,76 KiB
dst_fram.h	5BCFC4B0DFB08CC0E3893C8CD5F65178	2,93 KiB
dst_init.c	95804B316D5CB1125F44E24B3A8735DB	13,45 KiB
dst_init.h	AD9A4FDA75D866DC710131B72DB59B34	2,69 KiB
types.h		A3C28858774FD4A07B2E1740E5C7A9D3	9,36 KiB
unpack_dst.c	6F9D6BD5A9CA8CB4BC7CDFF35D767E90	35,93 KiB
unpack_dst.h	6633B0C66D04C51A142688DC60E111F0	2,71 KiB
yarn.c		F9778BE276FEDC00DC5D59BD2EEDB576	10,5 KiB
yarn.h		3D5CDB9442C5B9491B33B6E1809DF485	6,3 KiB

 

 

ISO extraction via CLI successfully finished:

 

sacd_extract -i 192.168.178.53:2002 -I
Processing [Mark Knopfler - Shangri-La.iso] (1/1)..
Completed: 100% (3656,3MB), Total: 100% (3656,3MB) at 1,59MB/sec

Yet still no playback - thats enough I will fire up Windows to get confirmation whether the ISO is really faulty or not.

[Nexus3]

The damn ISO was fine after all ? (never cuddle a Penguin without keeping the Windows open ? )

 

 

So the original assessment stands ...

[mindset]

51 minutes ago, Nexus3 said:

 

I surely hope so, here are the MD5sums from /sacd-ripper/libs/libdstdec/ :

Could you please post md5sums of sacd-ripper/libs/libsacd instead?  I have not made any change to libdstdec so I cannot tell whether you have the latest commit or not by comparing libdstdec's md5sums.

 

Alternatively you can do this to get the latest from the repository:

git clone https://github.com/setmind/sacd-ripper.git

 

On my side, I just tried iso2dsd in my Linux setup.  It extracts DSFs fine, and they play fine.

[Nexus3]

Just now, mindset said:

Could you please post md5sums of sacd-ripper/libs/libsacd instead?

 

 

Sure:

 

4bf7d260755dbe795d0d2d72da4ec0dc *libsacd\cuesheet.c
ee7797f38983b2c5a32ffaeb341d50c5 *libsacd\cuesheet.h
0cfe0bfa1720abac77104d306e953263 *libsacd\dsdiff.c
b2fb43a6c430f88e5a5f0abd5128e9a9 *libsacd\dsdiff.h
48096935af12146efbf1bd5e36d12f00 *libsacd\dsf.c
c24309f90c6b7ae72a14f1b371841e2a *libsacd\dsf.h
907c2750f060dbe6766127ec76f933bf *libsacd\dst_decoder_ps3.c
d43f36e112cafffb77bd6366fa8ef60e *libsacd\dst_decoder_ps3.h
6bc2865c768863e1b6c00d49ba3c1683 *libsacd\endianess.h
910998e04a5ffafffebfb5e2926d525c *libsacd\ioctl.c
8817902d77aadc3b31a770fdb6518b92 *libsacd\ioctl.h
c2331d84481b77ceb6b91fe1478c4d23 *libsacd\iso_writer.c
78b757c2db232ca1c418b98a04b8face *libsacd\Makefile
fcac2b183cd5ea94702f5a38bc241eac *libsacd\sac_accessor.c
4c8579f012d27511ea6e1f19e5708ec7 *libsacd\sac_accessor.h
f401439a984dfdd205115528a01e37f4 *libsacd\sacd_input.c
ea2878580b8119cfb687520616abc1dc *libsacd\sacd_input.h
5ce96ec15c7814596d3969991af018b8 *libsacd\sacd_pb_stream.c
671a793f4e6a4ccd2aed18e214ed3d72 *libsacd\sacd_pb_stream.h
aecacb5e2063a77ac355a21bcc1f4ccf *libsacd\sacd_read_internal.h
1183d93166df75ee8491b52b497d530f *libsacd\sacd_reader.c
53195ccf505f33155bbfa0d36d8d07c6 *libsacd\sacd_reader.h
a05f948b6afce3911587620fefa8e6d5 *libsacd\sacd_ripper.pb.c
1675b3dd3281be83948a7e322a3fdabe *libsacd\sacd_ripper.pb.h
3ec49fa842233bc6f6eaf94665a7b8de *libsacd\sacd_ripper.proto
35a299349c733761e5136036fdd48738 *libsacd\scarletbook.c
6fe58f9dbcc6cc0fe673e63e0709efe7 *libsacd\scarletbook.h
2adcfc86719941b69d1b2ead5ad653a8 *libsacd\scarletbook_helpers.c
eb85b896f0b4e4af083d452d2cb8fa4b *libsacd\scarletbook_helpers.h
1d2b2179e5e91d7c443367539dcd974b *libsacd\scarletbook_id3.c
5dd9db4904ad28938666f167310ccdcd *libsacd\scarletbook_id3.h
82370f631c3eb8ad3f07d92606c3dd23 *libsacd\scarletbook_output.c
a468553adfea5575312a27ec796181d5 *libsacd\scarletbook_output.h
978e5014deeefbbdb496498dc9ace598 *libsacd\scarletbook_print.c
db53e092e1682452dd12aa22f168869c *libsacd\scarletbook_print.h
83b7e34c694ddce324cd74c3bded5d76 *libsacd\scarletbook_read.c
5f4fa36055da2b71a58eabc67b1fa0f5 *libsacd\scarletbook_read.h
afc2736cfb871b24956ebf56bc86d806 *libsacd\version.h

 

[BluRay444]

4 hours ago, Nexus3 said:

 

@mindset

I stand corrected, your sacd_extract is indeed working but is incompatible with the java GUI [iso2dsd_gui.jar] in certain circumstances.

 

DST to DSD conversion errors:

sacd_extract: /.../sacd-ripper/libs/libdstdec/buffer_pool.c:138: buffer_pool_free: Assertion »count == pool->made« not satisfied.

or

sacd_extract: /.../sacd-ripper/libs/libdstdec/dst_decoder.c:307: write_thread: Assertion »dst_decoder->decode_head == NULL && peek_lock(dst_decoder->decode_have) == 0« not satisfied.

 

If the CLI is used, the output is valid:

 

sacd_extract -i 192.168.178.53:2002 -2 -c -s -t 1

sacd_extract -i 192.168.178.53:2002 -m -c -p -t 2

 

@ALL

 

If you aim for ISO output or just a plain DST extraction of the tracks (without a decompression to raw DSD), you can use the GUI with minset's sacd_extract.

 

If you desire uncompressed DSD files as output you should avoid the GUI and use the CLI directly. The speed gains are considerable!

 

Timely post... I was trying to convert to DSD a couple of days ago, but couldn't get it to work, wasn't sure if I had the syntax right, but it looks like I did:

 

 

c:\SACD_EXTRACT\sacd_extract.exe -i 192.168.1.65:2002 -m -c -P

 

c:\SACD_EXTRACT\sacd_extract.exe -i 192.168.1.65:2002 -2 -c -P

 

Prints out disc and track info but no files are extracted/converted. Same commands work fine with -c replaced with -s or -p to extract Sony DSF or Philips DDSDIFF files, and ISO files extracted without issue.

 

Hardware is Oppo BDP-103 and Win 7 Ultim 64bit CLI

 

Don't know what version sacd_extract.exe is, it was bundled with Ted_B's Autoscript with MD5 hash:

 

db075a77f1b714ddc6c0b3cdb7bc0aee  (for the extracted .exe)

 

The help and usage files include the -c option for DSD extraction.

 

Any thoughts?

 

[mindset]

3 hours ago, Nexus3 said:

Sure:

Thanks, it looks like you have the latest commit.  It is a really difficult one to debug since I cannot reproduce the problem.

[mindset]

1 hour ago, BluRay444 said:

 

Timely post... I was trying to convert to DSD a couple of days ago, but couldn't get it to work, wasn't sure if I had the syntax right, but it looks like I did:

 

 

c:\SACD_EXTRACT\sacd_extract.exe -i 192.168.1.65:2002 -m -c -P

 

c:\SACD_EXTRACT\sacd_extract.exe -i 192.168.1.65:2002 -2 -c -P

 

Prints out disc and track info but no files are extracted/converted. Same commands work fine with -c replaced with -s or -p to extract Sony DSF or Philips DDSDIFF files, and ISO files extracted without issue.

 

That is expected.  None of the options you gave to sacd_extract are specifying the output format so there is no way for it to do any processing.  You need to give either -s, -p, -I, or -e.

 

 

[mindset]

4 hours ago, Nexus3 said:

 

Sure:

 

pre widget

4bf7d260755dbe795d0d2d72da4ec0dc *libsacd\cuesheet.c
ee7797f38983b2c5a32ffaeb341d50c5 *libsacd\cuesheet.h
0cfe0bfa1720abac77104d306e953263 *libsacd\dsdiff.c
b2fb43a6c430f88e5a5f0abd5128e9a9 *libsacd\dsdiff.h
48096935af12146efbf1bd5e36d12f00 *libsacd\dsf.c
c24309f90c6b7ae72a14f1b371841e2a *libsacd\dsf.h
907c2750f060dbe6766127ec76f933bf *libsacd\dst_decoder_ps3.c
d43f36e112cafffb77bd6366fa8ef60e *libsacd\dst_decoder_ps3.h
6bc2865c768863e1b6c00d49ba3c1683 *libsacd\endianess.h
910998e04a5ffafffebfb5e2926d525c *libsacd\ioctl.c
8817902d77aadc3b31a770fdb6518b92 *libsacd\ioctl.h
c2331d84481b77ceb6b91fe1478c4d23 *libsacd\iso_writer.c
78b757c2db232ca1c418b98a04b8face *libsacd\Makefile
fcac2b183cd5ea94702f5a38bc241eac *libsacd\sac_accessor.c
4c8579f012d27511ea6e1f19e5708ec7 *libsacd\sac_accessor.h
f401439a984dfdd205115528a01e37f4 *libsacd\sacd_input.c
ea2878580b8119cfb687520616abc1dc *libsacd\sacd_input.h
5ce96ec15c7814596d3969991af018b8 *libsacd\sacd_pb_stream.c
671a793f4e6a4ccd2aed18e214ed3d72 *libsacd\sacd_pb_stream.h
aecacb5e2063a77ac355a21bcc1f4ccf *libsacd\sacd_read_internal.h
1183d93166df75ee8491b52b497d530f *libsacd\sacd_reader.c
53195ccf505f33155bbfa0d36d8d07c6 *libsacd\sacd_reader.h
a05f948b6afce3911587620fefa8e6d5 *libsacd\sacd_ripper.pb.c
1675b3dd3281be83948a7e322a3fdabe *libsacd\sacd_ripper.pb.h
3ec49fa842233bc6f6eaf94665a7b8de *libsacd\sacd_ripper.proto
35a299349c733761e5136036fdd48738 *libsacd\scarletbook.c
6fe58f9dbcc6cc0fe673e63e0709efe7 *libsacd\scarletbook.h
2adcfc86719941b69d1b2ead5ad653a8 *libsacd\scarletbook_helpers.c
eb85b896f0b4e4af083d452d2cb8fa4b *libsacd\scarletbook_helpers.h
1d2b2179e5e91d7c443367539dcd974b *libsacd\scarletbook_id3.c
5dd9db4904ad28938666f167310ccdcd *libsacd\scarletbook_id3.h
82370f631c3eb8ad3f07d92606c3dd23 *libsacd\scarletbook_output.c
a468553adfea5575312a27ec796181d5 *libsacd\scarletbook_output.h
978e5014deeefbbdb496498dc9ace598 *libsacd\scarletbook_print.c
db53e092e1682452dd12aa22f168869c *libsacd\scarletbook_print.h
83b7e34c694ddce324cd74c3bded5d76 *libsacd\scarletbook_read.c
5f4fa36055da2b71a58eabc67b1fa0f5 *libsacd\scarletbook_read.h
afc2736cfb871b24956ebf56bc86d806 *libsacd\version.h

 

Although I said these are the latest, actually these are *NOT*.   Please try using the latest commit using the git command I provided before.  It has the fix for the problem you mentioned.

[mindset]

55 minutes ago, mindset said:

Thanks, it looks like you have the latest commit.  It is a really difficult one to debug since I cannot reproduce the problem.

Please disregard this reply.   You are actually using pretty old codes.

[BluRay444]

6 hours ago, mindset said:

 

That is expected.  None of the options you gave to sacd_extract are specifying the output format so there is no way for it to do any processing.  You need to give either -s, -p, -I, or -e.

 

 

What I didn't mention before is that I previously had tried other variations that included:

 

c:\SACD_EXTRACT\sacd_extract.exe -i 192.168.1.65:2002 -m -c -s -P

 

c:\SACD_EXTRACT\sacd_extract.exe -i 192.168.1.65:2002 -m -s -c -P

 

...which both result in DSFs...

 

Why don't you give me a properly formatted command to extract and convert from Sony DSF format to DSD so I can understand what I'm doing wrong?

 

[mindset]

5 hours ago, BluRay444 said:

Why don't you give me a properly formatted command to extract and convert from Sony DSF format to DSD so I can understand what I'm doing wrong?

 

I can't because DSD is not a file format but just an audio modulation scheme.  The only output format sacd_extract can output is DSF, DSDIFF,  DSDIFF edit master and ISO and these contain DSD in either DST-compressed or uncompressed format..

 

The "-c" option (convert DST to DSD) is only applicable to DSDIFF output format which can support both DST-compressed and uncompressed DSD.  This option is not applicable to DSF or ISO because DSF can only support uncompressed DSD, and ISO maintains the original (either DST-compressed or uncompressed).

 

[BluRay444]

Thanks mindset... right after I wrote my last post I realized I needed to go back to pre-schooler school and get straight in my mind the relationship between DST, DSF and DSDIFF, and that is what I've been doing for the past few hours. 

 

mindset said "I do not know what you were getting that old version of sacd_extract."

I did mention I got it from Ted_B's Autoscript (in this thread), how could you tell that it was an old version of sacd_extract?

 

I think the bottom line is that when I extract files from SACD's, I only need the DSF version because it's uncompressed  DSD (which is what I want) and has better native support for metadata (DFF can store metadata ID3 format in the DFF's internal data block, but the DFF file player must also be capable of recognizing ID3 chunks).

Have I got it right?

 

Thanks for your help.

[Darryl R]

21 hours ago, Dick Darlington said:

How I Spent My Summer Vacation, Found Love and Ripped My Very First SACD:  PART 1 of <there is no telling>

My new Pinchas Zukerman / English Chamber Orchestra Vivaldi: The Four Seasons SACD arrived in the post yesterday ? and I decided to combine the ISO ripping process with a demonstrative experiment?, primarily for the benefit of newcomers, but also with the hope of presenting a simple validated near-universal AutoScript proven to work with both the Sony and Oppo player classes.

 

For the noobs, I trust this will demonstrate how simple how simple this process actually is with a properly composed AutoScript and strict attention to tried and true procedures.

 

Also for the noobs, I hope to demonstrate that incorporating optional Telnet access into your script even if you plan to use the server method exclusively:

• Costs you absolutely nothing.
• Will not in any way shape or form prevent your script from working.
• Will ensure that the option to look at what’s going on inside the player will always be there when/if the need arises.
• Will be a troubleshooting timesaver and help those trying to help you figure out what you are doing wrong if you can’t get the process working. (And make no mistake: if you face plant on your initial attempts, it’s not the script; it’s not telnet; it’s you.  There are a dozen show stopper things you could do wrong, and if you use this script without success then you have tripped over at least one of them.  Better to embrace that and find the problem quickly than to spin your wheels whilst generating mis-information that will confuse those that will follow.)

So if you find yourself confounded and asking for help, think of using a Telnet enabled script as a courtesy to those volunteering their time to help get you up and ripping.  Just a thought. ?

 

If nothing else other than to rip my new SACD, I wish to establish as fact that just because there are myriad scripts (not to mention posts) that treat Telnet access and the so-called "server method" as mutually exclusive doesn't mean it has to be that way and thus unnecessarily complicated.

 

To this end, and to present with absolute confidence a near-universal Telnet+Server Method AutoScript for use with either the Sony or Oppo players I decided to set aside my trusty tried and true AutoScript USB drive and start from scratch as if I was going through the process for the very first time. "Like a Virgin" { Dick goes off the rails again.  This time channeling his inner Madonna. }

 

Again, for noobs please know that there are many variations to what I’m presenting here that will also work.  For instance I could have used NTFS instead of FAT32.  I chose the former simply because it’s more convenient in my case since my primary computer is a Mac.

 

In other words I am NOT claiming things must be done exactly this way.  I AM claiming that if you use this script in the manner I just did (that is with a properly prepared USB drive and a properly configured computer on the same network with your Sony S590 player) it WILL work for you.

 

If you do this and it does not work, then you have done something wrong because a) it works and b) it's damn easy. <hmmm I wonder if this is a good time to plug my online real estate wealth classes? ?>.

 

The following script and steps worked flawlessly for me on the first go with my S590.  And without a hitch on my first pass when I repeated it (with a few player specific changes) using my Oppo 103.

 

So without further adieu, here is how I started from scratch and ripped my new SACD earlier today; first using my Sony S590 and then again using my Oppo 103:  (note that the procedure for the Oppo varied slightly from the following Sony procedure due to player differences but the script used was identical save for the “_160” needing to be removed from lines 9 and 10 when used with the Oppo.

 

1. I grabbed a random 8 GB USB stick and reinitialized and formatted it as a Master Boot Record type disk with a single FAT32 volume in accordance with the USB drive preparation guidelines that have been provided many times over on this thread.
2. On my Windows computer (see note below that I may or may not remember to add regarding why I chose to use Windows instead of my Mac for this step) I created a new folder named “AutoScript”.
3. I placed a copy of the Linux “sacd_extract” and “sacd_extract_160” binary files into the AutoScript folder to support ripping on the Oppo and the Sony players respectively.
4. I created a new, empty text file named “AutoScript.TSS” ensuring that it did NOT contain the default “.txt” extension, hidden or otherwise, and placed it inside the the AutoScript folder alongside the two Linux programs.
5. Using Notepad, I opened AutoScript.TSS for editing and entered the following lines of script.  FWIW I actually cut and pasted the non-commented out lines directly from my own highly annotated universal AutoScript file that up until yesterday I had made available to the community in my DropBox folder. (see note below that I may or may not remember to add regarding why having my annotated universal AutoScript file publicly available was a monumentally bad idea and why I have removed it from the DropBox folder.). The exact, character for character contents of my freshly composed AutoScript.TSS file are as follows:
6. Taking a moment to pause and inspect my handiwork, I took note of the fact that some lines, such as the ones affecting the player’s character display and the final line that opens the tray are in no way required for the ripping process to work.  I just like them there and they do serve a purpose, albeit nonessential.
7. I took a moment to contemplate how necessary if at all the SLEEPMS lines are.  I resolved to save that experiment for another day.
8. I felt a pang of chagrin at not remembering who the contributor is that provided a more robust version of the “CLI_exec cp /mnt/sda1…” line that eliminates the point of failure of the mount point ending up different than “sda1” so that I could PM him instead of searching half the thread to find it and being too lazy to do so.  Sigh.

{ Note to noobs: steps 6 - 8 above are not actually required }

9. I copied my shiny new AutoScript folder containing AutoScript.TSS and the sacd_extract binaries to the root folder of my freshly formatted USB drive and removed it from the computer.
10. I unplugged the player from AC power and momentarily plugged it back in. (This was to ensure that any previously running Telnet and/or sacd_extract_160 processes were terminated AND MOST IMPORTANTLY to ensure the USB disk would mount in the expected /mnt/sda1 location. Hence step 8 above.)
11. I powered up my Sony player and confirmed that “Quick Start Mode” was set to ON (available in Setup->System Settings) and confirmed that the IP address was what I believed it to be (available in Setup->Internet Settings->View Network Status).
12. I opened a macOS terminal window on my Mac and employed the ping command to confirm network connectivity to the player at the IP address verified earlier.
13. I penetrated the player’s slot (specifically the front slot) with my virgin USB stick and hoped for a response.
14. Within a few seconds I observed “0000” on the character display (pronounced oh oh oh oh) followed soon after with the tray coming out and the display changing to “home”.
15. In order to assess that all was on track I used netcat (the “nc” command on my Mac to verify that the player was indeed listening attentively on both the Telnet and sacd_extract ports; ports 23 and 2002 respectively. (This would generally be a troubleshooting step and not normally performed otherwise BTW.)  The macOS commands I used (specific to my player’s IP address of course) were:

nc player_ip_address -vz 23

and

nc player_ip_address -vz 2002

 

The results of both nc queries were positive confirming that both Telnet and sacd_extract_160 were running on the player.

16. I opened a Telnet session on the player from my Mac using the command:  telnet 10.10.42.69.  When prompted by the player I entered the username “root” sans quotes, hit Enter, and I was in like Flynn.
17. Just for grins I entered the command: “ps” sans quotes to list all of the currently running processes and indeed sacd_extract_160 running in server mode was listed.  Winning!  (Note that at this point had I wanted to rip locally to the USB drive I could have simply killed the running sacd_extract_160 process and proceeded in accordance with the S590 Guide.
18. I laid my new SACD on the now open tray and … IMPORTANT … PAY ATTENTION … I WON’T SAY IT AGAIN … hit the power ON/OFF button on the player which in turn closed the tray and put the player into a sleep state.
19. Back on my Mac I launched the Sonore ISO2DSD GUI and selected Server Input, Print, and Raw ISO Output Mode.
20. I entered the player’s IP address appended with 2002 into the IP Address | Port field.
21. I stood up and turned around thrice clockwise and thrice counterclockwise and returned to my seat.  (Optional but recommended if you’ve been sitting for a while.)
22. I clicked on the ISO2DSD Execute button and waited for what felt like an hour but was in fact only 16 seconds and voila! The ISO2DSD output screen populated with disk and track information and the ripping process commenced.  A few minutes latter the title’s ISO image was on my Mac’s hard drive and ready for the next step in my workflow.
23. Pretending I wanted to re-rip my Aerosmith Toys in the Attic SACD, I opened the tray with the Open/Close button on the player; swapped disks and hit Power ON/OFF.  Allowing a few seconds after the tray closed I hit “Execute” in ISO2DSD again to initiate the second rip.

There is a slight caveat regarding step 23.  Powering the player on and off to rip multiple disk in one go should probably not be done while the USB stick remains inserted.  This is because the AutoScript will execute again with each cycle and in doing so launch another instance of sacd_extract.  That didn't present a problem on my second disk, but I expect the player would eventually become low on resources after some number of iterations.

 

Next Up:  The Oppo Experience:  A few minor differences and a touch of refined elegance.

 

Cheers! ?

 

Amazing, something we've been using for two years now, with just a few easy steps, has for some now become this.