EugenF

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.

Sorry, not for current/older versions of sacd_extract. Maybe in a future version I will do it.

Hi Kal, Indeed, my enhanced sacd_extract has default folder structure like you mentioned (a lot of people asked for that), with the execeptions of the discs which have only Stereo Area and there are not part of Disc Sets (it creates only Album name folder). There is no option to disable this feature. Maybe in a future version of sacd_extract I will do it. You need to use an old sacd_extract app from mindset or the original one.

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

A new build of enhanced client sacd_extract-0.3.9.3-88 has been uploaded on github: https://github.com/EuFlo/sacd-ripper/releases Changelog: - added long path support (>260 chars) only for Windows7/8/10 platforms; - minor changes to Performer option (if Performer asked to be inserted in filename but didn't exists on disc Album Artist or Disc Artist is used instead. 'unknown performer' is used as a last resort); - minor bug fixed of wrong variables assignation (from original fork). When these metadata are present on SACD: area_description, area copyright, area description_phonetic or area copyright_phonetic, all are incorrectly assigned to the same variable area.description.

Thanks for sharing this info. I am happy you solved the pops/crackles. If I understand correctly: you use dff format not dsf format. Dff files can be created with DST decompression option ON of OFF. What option did you used?

Pauses=0 means pauses between tracks are not included. As a result the dsf files will have the corect duration in time as stated on the cover of album (to reflect the correct playing time of tracks specified in Tracklist found on disc). All the audioframes that has the timecode outside the interval [tracklist_time_start_track, tracklist_time_start_track + track_duration] will be discarded. There are some discs that don't follow this rule. So setting pauses=1 can rip all the audioframes it exists on that disc. Can you tell us what is title of the album?

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

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.

Now we have macOS version of improved sacd_extract 0.3.9.3-71: https://github.com/EuFlo/sacd-ripper/releases/tag/0.3.9.3 Also for Windows and Linux. Revision 0.3.9.3-71 has an updated ID3tag character encoding.

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

Hi Antonello, I modified the CMakeLists.txt to be compatible with arm64. It should compile now.

So do I.

Hello everyone! I build an improved sacd_extract client app (for Windows and Linux, not Mac, sorry, maybe later ) with lots of new features (long filenames, wide chars in filename, pauses removal, concatenation of dsf tracks, fully metadata in ID3V2.3/ID3V2.4 UTF-8 tags, etc) which can solve lots of dsf output problems. It is fully compatible with SACDExtractGui or Sonore/ISO2DSD. Uploaded the release-candidate version of sacd_extract ver 0.3.9.3-63 (now it has version control based on commit hash in github): https://github.com/EuFlo/sacd-ripper/releases/tag/0.3.9.3 or https://github.com/EuFlo/sacd-ripper/releases/download/0.3.9.3/sacd_extract-0.3.9.3-63-win64.zip Stay safe!!! Please take good care of your health!

Indeed not working well with -z option. 😥 Now fixed the problem. Thanks for feedback @austinpop!