Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[Awesome Donkey]

Since RD James mentioned wanting to disable SACD to DSD conversions in MC due to the DSD > PCM > DSD conversion step, I've got two alternative ideas maintaining such conversions without any re-encoding needed so there's no DSD > PCM > DSD conversion. This is the first, more "simple" idea of the two...

1) Allow MC to 'convert' DFF files to DSF files or DSF files to DFF files without doing any re-encoding whatsoever. It's possible to repackage a DFF file to a DSF file (or vice versa) without doing any re-encoding as there's a tool called dff2dsf which does this and it works well. The problem with dff2dsf? It's macOS-only and does the repackaging one way (DFF to DSF).

This would save users interested in such conversions some trouble since many users don't realize DSD to DSD conversions in MC (and other apps) go through a PCM step in the middle. The idea here is to eliminate the need for the PCM conversion step when doing specific DSD to DSD conversions. This would should actually be simple to figure out by taking a DFF file, extract the DSD audio data contained within and repackage that audio data as a DFF file. Then figure out how to do the reverse DSF to DFF repackaging.

The second idea is likely more complicated. As you know, there's a tool called sacd_extract that can take a SACD ISO and extract (either the stereo and/or the multichannel) tracks to individual tracks. It seemingly does this by extracting the track's DSD audio data and (without doing any re-encoding) repackaging that do either a DFF file or DSF file.

2) Either modify the convert format tool or add a new SACD extracting tool to extract tracks from a SACD ISO (and not a SACD disc, obviously) without doing any re-encoding (just extract the data and package it like sacd_extract seemingly does) and of course give the user the option of either DFF or DSF files for the output.

Why consider this?

1) This would more-or-less eliminate the majority of DSD > PCM > DSD conversions... well, except when using output format to convert PCM/DSD64 to DSD128 for example of course. However, this is probably the biggest benefit and would save users precious time (e.g. when they realize there's a PCM conversion step, then having to use sacd_extract or ISO2DSD to extract DSF files from a SACD ISO again).
2) This would eliminate the need for external tools like sacd_extract, ISO2DSD (which as far as I know requires Java) and the macOS-only dff2dsf tool.
3) No other media player app, to my knowledge, does this. MC would be the first. It would greatly improve MC in regards to SACD/DSD playback and management.

I personally would use this... a lot. Right now my workflow with extracting individual files from SACD ISOs is I have to use sacd_extract from the command line to extract DFF files then boot into macOS to repackage the DFF files to DSF files (I don't extract directly to DSF because of the known glitch issue with DSF that was seemingly fixed in sacd_extract but still happens to me). However if the second part of the request is too complicated I'd honestly be happy with having the ability to repackage DFF files to DSF files (or vice versa) without doing any re-encoding.

Thoughts?

[dtc]

I have used Vinyl Studio on Windows to do dff to dsf conversions. I am pretty sure it does not go through PCM. It is only $29 and does a lot of other nifty stuff. The author is very responsive on his forum.

Vinyl Studio also will save a file in DoP format, for the rare occasion that people want to do that.  There used to be devices that used that format but did not have software to create DoP, so they required the DoP to be saved in files that could be feed to the DAC. Those are pretty much gone.

[InflatableMouse]

The second idea is likely more complicated. As you know, there's a tool called sacd_extract that can take a SACD ISO and extract (either the stereo and/or the multichannel) tracks to individual tracks. It seemingly does this by extracting the track's DSD audio data and (without doing any re-encoding) repackaging that do either a DFF file or DSF file.

I'm pretty sure this will never happen. The reason is simple, I don't think there is SACD hardware available for PC's or MAC's.

The format is Sony proprietary and the only thing capable of SACD reading and decoding are SACD players (as in, hifi devices) and older PS3 models with old firmware (not updated). PC's or MAC's will never get it (at least not any time soon).

[dtc]

I'm pretty sure this will never happen. The reason is simple, I don't think there is SACD hardware available for PC's or MAC's.

The format is Sony proprietary and the only thing capable of SACD reading and decoding are SACD players (as in, hifi devices) and older PS3 models with old firmware (not updated). PC's or MAC's will never get it (at least not any time soon).

There is now software that allows extracting ISOs using certain models of Oppo, Pioneer and Sony players.  That has made SACD ripping much more common that just using the old PS3s.

https://audiophilestyle.com/forums/topic/28569-sacd-ripping-using-an-oppo-or-pioneer-yes-its-true/

[kr4]

I personally would use this... a lot. Right now my workflow with extracting individual files from SACD ISOs is I have to use sacd_extract from the command line to extract DFF files then boot into macOS to repackage the DFF files to DSF files (I don't extract directly to DSF because of the known glitch issue with DSF that was seemingly fixed in sacd_extract but still happens to me). However if the second part of the request is too complicated I'd honestly be happy with having the ability to repackage DFF files to DSF files (or vice versa) without doing any re-encoding.

Thoughts?

There are, also, two other options. 
(1) A script (by Bogi) to convert the ISO to DFF, while temporarily storing the metadata, followed by a conversion to DSF and subsequent restoration of the metadata.
(2) A new equivalent of sacd_extract which is faster and does not suffer from the DSF glitch.
 

[Awesome Donkey]

I'm pretty sure this will never happen. The reason is simple, I don't think there is SACD hardware available for PC's or MAC's.

Oh, sorry I wasn't clear, but I wasn't talking about ripping SACD discs, but SACD ISOs that have been imported within MC.

Also, there's a fork of sacd_extract that's being maintained with additional features!

[RD James]

It would be preferable if Media Center could split ISOs and manage the metadata, but I do think that blocking the SACD>DSD conversion is the best option if they are unwilling to dedicate resources to it.
I'm still somewhat hesitant to split up my files because it seems like every version of sacd_extract produces a different checksum for extracted tracks, and there are issues playing individual tracks which seem to be player-specific.

However, Media Center's ISO support is in an awful state right now.
You can't rename/move ISO files, and seemingly at random (though I'm sure someone could figure out a cause) the tracks "lose" the track number assignment - so "album.iso;1" becomes "album.iso" and the tracks won't play any more. Or the metadata is reset to whatever is stored on the disc, and all previous customizations are lost.
 
Something that does work to some degree is setting up sacd_extract.exe in the send to > external menu. There, you can set up a preset which will extract the selected album to individual tracks.
The only issue is that you'll need three presets:

• One for stereo-only (uncompressed) discs to extract DSF tracks.
• One for stereo tracks on a multichannel disc (DST-compressed) to extract DFF tracks.
• One to extract the multichannel tracks from a multichannel disc to DFF.

(2) A new equivalent of sacd_extract which is faster and does not suffer from the DSF glitch.

Could you be more specific about the "DSF glitch" ?

There was an issue with 0.37 (from 2015) where DSF export truncated samples, which was fixed in 0.38.
But the updated 0.39 build from "setmind" adds an option to remove zero-padding at the end of DSF tracks because some players do not handle it correctly and will play a click/pop at the end of a track. I'm not sure whether JRiver is one of them, or whether using this option would be detrimental if the player does handle the padding correctly.

Or do you mean something else?

Also, there's a fork of sacd_extract that's being maintained with additional features!

I've built the latest version of this (with the latest commits - so you could think of it as "0.40") for Windows and attached it to my post.
Be warned: it seems to have some behavioral changes from the main sacd_extract, such as overwriting files if they already exist, rather than creating another directory with incremental numbers added to it; e.g. "Album", "Album (1)", "Album (2)".
I'm not sure why that change was made, especially when it also created a bug in 0.39 that didn't handle unicode characters properly (silently failed to extract anything).

[Awesome Donkey]

I just tested the sacd_extract fork, and it produced DSF files without the "glitch", which work perfectly in MC. I can now eliminate dff2dsf from my workflow.

You might report the overwriting files thing to the author, as sacd_extract looks to be in very active development.

setmind also created a GUI tool for sacd_extract as well (which requires Java): https://github.com/setmind/SACDExtractGUI

[RD James]

I just tested the sacd_extract fork, and it produced DSF files without the "glitch", which work perfectly in MC. I can now eliminate dff2dsf from my workflow.

Okay, but what is the glitch that you're referring to?

You might report the overwriting files thing to the author, as sacd_extract looks to be in very active development.

For what it's worth, it seems to only affect albums with unicode metadata. Other albums are behaving as expected.

[Awesome Donkey]

Well, for example if I extract DSF files (using the original sacd_extract) from a SACD ISO, let's say a Pink Floyd album (either Dark Side Of The Moon or Wish You Were Here) where all tracks segue into each other, there's an audible "pop"/"click"/"glitch" exactly at the point when the track changes (gapless playback is enabled, BTW). It only affected DSF files, as I could extract DFF files and they'd be fine. Then from there going into macOS to use dff2dsf to repackage them to DSF (the glitch wasn't present when doing that).

I know that DSF "glitch" was supposed to be fixed in the newest sacd_extract, but it never worked for me so I had to extract to DFF first then repackage to DSF. But this new sacd_extract works perfectly for me.

[kr4]

Could you be more specific about the "DSF glitch" ?
.......................................................
Or do you mean something else?

That is it and Bogi's script gets around it.

I've built the latest version of this (with the latest commits - so you could think of it as "0.40") for Windows and attached it to my post.

What I was referring to but without the link.

[TheShoe]

Well, for example if I extract DSF files (using the original sacd_extract) from a SACD ISO, let's say a Pink Floyd album (either Dark Side Of The Moon or Wish You Were Here) where all tracks segue into each other, there's an audible "pop"/"click"/"glitch" exactly at the point when the track changes (gapless playback is enabled, BTW). It only affected DSF files, as I could extract DFF files and they'd be fine. Then from there going into macOS to use dff2dsf to repackage them to DSF (the glitch wasn't present when doing that).

I know that DSF "glitch" was supposed to be fixed in the newest sacd_extract, but it never worked for me so I had to extract to DFF first then repackage to DSF. But this new sacd_extract works perfectly for me.

i only ever had that pop/click problem with kodi and dsf.  and kodi never supported multichannel dsf which is a provlem for me given the amount of multichannel audio i have.

jriver never had that issue for me and i never bothered with new versions of sacd_extract.   when was it fixed?

stopped using kodi a few years back now because jriver does it all. 

[redwall]

I know this thread is quite old at this point, but I've noticed JRiver has been managing my SACD iso albums better than it was several months ago, ie it's not losing the tracks/ only showing the first track, etc. Anyone else had this experience?