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

[EugenF]

On 10/4/2019 at 1:49 AM, mlknez said:

 

Thank you for the reply.  I tried using that version of SACD_extract.  I have some SACD .iso files that hang at 99% when extracting .dsf files.  The source .iso files play just fine on jriver 25.  Anyone have this issue?  Any fixes?

I used to have the same problems with iso file. 

I managed to make some improvements to sacd_extract to resolve the 99% infinite loop.

If you want to try it can be found here (version for Windows & Linux):

https://github.com/EuFlo/sacd-ripper/releases/tag/0.3.9.3

 

[EugenF]

11 hours ago, Timb5881 said:

Found an SACD that does not rip well.  The soundtrack to O Brother Where Art Thou.  Tried ripping it twice and file always comes out as unreadable.  No problems with the other's I have ripped.

Hi Timb5881,

Please try my sacd_extract app  (Windows or Linux only) to see if it can rip well.

 

https://github.com/EuFlo/sacd-ripper/releases/tag/0.3.9.3

 

 

[EugenF]

10 hours ago, Timb5881 said:

So do your files, do they go on the flash drive?   I should point out that the files get ripped but when I play back the files I get an error:

Unable to open item for playback (Seek offset out of range):
"E:\Various Artists - Original Soundtrack - O Brother, Where Art Thou\01 - James Carter & the Prisoners - Po Lazarus.dff"

Unable to open item for playback (Seek offset out of range):
"E:\Various Artists - Original Soundtrack - O Brother, Where Art Thou\02 - Harry McClintock - Big Rock Candy Mountain.dff"

 

It looks that flash drive is full and cannot write dff files (there are empty files)

Try to rip ISO file only on the flash. Then try to convert ISO file to DFF/DSF files on desktop/laptop.

 

[EugenF]

12 hours ago, austinpop said:

 

I have 2 questions to pose to the group experts:

1. has there been any progress on this pop/crackle issue in later releases of sacd_extract?

I have made a small progress in updating the sacd_extract (in a pre-release ver.  0.3.9.3) by take in account of Track_Start_Time  and Time Code for each audio frames belonging to that track.  And the padding is made with '0x69' s instead of '0x00's. See pm for more details.

[EugenF]

I someone are interested in testing an improved pre-release version of sacd_extract (wide char filenames - for Windows version, long names of folders, more integrity checks of audio frames, exporting xml file with metadata form disc and more) here is my compilation:

 

https://github.com/EuFlo/sacd-ripper/releases/tag/0.3.9.3

 

Now is fully compatible with SacdExtractGui (including nopad option).

 

 

[EugenF]

Now I fixed 2 more bugs in original dsf.c source code!!!!

Just  updated the builds of sacd_extract.

 

Link is the same:

https://github.com/EuFlo/sacd-ripper/releases/tag/0.3.9.3

 

Please test it.

[EugenF]

13 hours ago, Sidemounter said:

In reply to EugenF's interesting offer some 26 or so minutes ago [***], is there any chance of a parallel version for MacOS, please ? We're not all using 'Windoze' (any more...) ...   Thanks in advance for any hint as to whether this is even a possibility, and (if so) when I should start to be hopeful ! 

 

(*** : "I someone are interested in testing an improved pre-release version of sacd_extract (wide char filenames - for Windows version, long names of folders, more integrity checks of audio frames, exporting xml file with metadata form disc and more) here is my compilation: ......................")

Don't have a toolchain setup to compile for MAC yet (nor hardware to test it). Sorry 😞. In the near future will try to setup a right toolchain for cross compile with apple target.

[EugenF]

11 hours ago, lordvader said:

 

Please tell me I don't need to re-rip everything?

Not for now. Only test it on a few iso's.

Maybe when the app passes a lots of tests it will be worth re-ripping.

[EugenF]

2 minutes ago, BlueSkyy said:

Thanks very much!  It would be helpful if you implemented some more definitive version control so people like me don't get mixed up on what we are running.

Your are right, but I want to keep the same link and don't want to increase the version number for that moment.

[EugenF]

5 minutes ago, Kal Rubinson said:

I cannot imagine anything that would justify re-ripping a large library.  I can imagine switching to a new version for subsequent rips.

Indeed Kal!

ISO's ripped with old versions with sacd_extract are ok. Nothing changed fundamentally here.  

In case of dsf/dff files maybe only for those guys who are very sensible to pops/crackles noises.   

[EugenF]

@pmarinac:  It can be done in one command because sacd_extract can extract stereo and multichannel in a single run:  

for /F "usebackq delims==" %%I in (`dir /B *.iso`) do sacd_extract -2 -m -s -c -i "%%I"

[EugenF]

On 2/16/2020 at 1:24 PM, BlueSkyy said:

Thanks very much!  It would be helpful if you implemented some more definitive version control so people like me don't get mixed up on what we are running.

Starting from now version control is done.

[EugenF]

4 hours ago, BlueSkyy said:

 

Yippee!  Excellent for those of us who don't know what we've got!

Latest builds:

Version 0.3.9.3-23-gb562b812f5984d6d181dd21961d422c28484c0aa pre-release.

https://github.com/EuFlo/sacd-ripper/releases/tag/0.3.9.3

 

[EugenF]

21 minutes ago, haggis999 said:

I've just downloaded this latest version, but SACDExtractGUI only appears to display its own version number. I can't see any reference to what version of sacd_extract.exe is being run. Do I need new glasses or have I misunderstood what you mean by version control?

Version is shown with test button on SACDExtractGUI

or 

sacd_extract -v

And returned:

sacd_extract version 0.3.9.3, built commit hash: 0.3.9.3-23-gb562b812f5984d6d181dd21961d422c28484c0aa
 

Every version of  build is now taken from git commit hash to know what release is.

The future builds will have automatically (from git) numbers like this: 0.3.9.3-24-hash..., 0.3.9.3-25-hash.....

[EugenF]

On 2/19/2020 at 1:22 AM, austinpop said:

1. 0.3.9.3-23 pop is very slightly louder than the @mindsetversion in SACDExtreactGUI - but without "padding-less DSF."

Very funny  🙃 . In this case both apps are creating tracks with identical audio content, except mine adds a few more bytes for performer id3 tag. The first track generated by mindset app is bigger because pause is included in it.

[EugenF]

On 2/19/2020 at 1:22 AM, austinpop said:

0.3.9.3-23 pop is louder than the @mindsetversion in SACDExtreactGUI - with "padding-less DSF."

Indeed not working well with -z option.  😥

Now fixed the problem.

Thanks for feedback @austinpop!

[EugenF]

13 hours ago, mace said:

Actually, I've starting buying SACD's again now that I know I can rip them. 

So do I.

[EugenF]

12 hours ago, bradandbree said:

 

My next issue is the popping noise.  I was delighted when my re-converted .dsf files had just the slightest noise when changing tracks, although the combination of the non-gapless and noisy transition from movement 3 to 4 of Beethoven's 5th is almost enough to make me scrap my project altogether. However, I've noticed that when the tracks are multichannel, the popping noise is terrible, and happens both at the end of one track and the beginning of the next.

Dear Brad,

The crackles/pops noises of dsf files is indeed a real problem.  
This is specially very annoying when tracks has no pauses in between and the level of audio signal is high.

In my opinion, here are the main causes:

a) by definition, dfs files has ID3 tags located at the end of files. Players spend more time seeking and reading at the end of file then came back at the beginning of file to start playing. Dsf files are large ones. Multichannel dsf files are bigger. For a network transfer is a big stress. Even local transfer has problems with large file manipulations.
b) huge ID3tags with lots of information to process at playing time;
c) dsf files have incorrect data in dsd header, audio streams or ID3 tags;
d) dsd audio data stream is improper processed by players.

 

To reduce pops/crackles you can try made DSF files:
-  first test your player with DSF files having no ID3 tags. In this way it reveals if pops/crackles are caused by the player itself;
-  with minimal ID3V2.3 tags, the benefit is smaller ID3 data to process; 
-  with minimal ID3V2.4 tags, here the benefit is using syncsafe integers (of ID3 frame size) which will not interfere with audio data stream;
-  with padding-less option activated; 
-  concatenate dsf files.

 

You can try do all these by using this sacd_extract client app (Linux and Window - and in near future MAC version):

https://github.com/EuFlo/sacd-ripper/releases/tag/0.3.9.3

 

[EugenF]

Now we have macOS version of improved sacd_extract 0.3.9.3-71 (build for macOS with help of @Nexus3. Thank you!):

 

https://github.com/EuFlo/sacd-ripper/releases/tag/0.3.9.3

 

Also there are binaries for Windows and Linux too.

 

Revision 0.3.9.3-71 has an updated ID3tag character encoding.

[EugenF]

29 minutes ago, pl_svn said:

 

question:

this is the one to place inside the folder I'm ripping to (using Terminal) whilst on the USB key I keep the old one (for Oppo), right?

 

thanks

This is the client app which runs on desktop/terminal/laptop. Can work with Sonore ISO2DSD or SACDExtractGUI.

Not the one on usb key.  

[EugenF]

4 hours ago, stoutblock said:

So it should be the default mode in case some you have a disc that is in DST?  Is there any easy way to know if you have a disk that is DST rather than DSD?  If you try to rip something that is DST without this on, what a happens?  I read that most surround sound tracks are DST?

 

a) DSF files are always uncompressed, so DST is mandatory;

b) DFF files can have DST compresssion or not;

c) SACD's are always DST compressed when has multichannel area;

d) You can rip to ISO files. Then you can extract and convert ISO file to DSF or DFF files (see a, b);

e) Yes. see c).

[EugenF]

20 hours ago, meega said:

So, if there is interest, I will release it as open-source tool, but you still need to extract and use "sacd_read.ko"

One year ago, after 6 months of research, I succeed to build a standalone app for an iso direct ripping on a usb flash drive.

It was a concept proof for educational purposes only and can be run on all ARM brand players (armv6/linux kernel 2.6.27 and armv7/ kernel 3.10, or a mix of them).

Of course the app uses the appropriate kernel driver/module sacd_read.ko only (I did not use WD TV Play).

 

So there is an interest here. Please release it.

If I can (and have time), maybe I can help.