Topic: DST compressed .dff files support (Read 18715 times)

rael71 · « **on:** September 23, 2012, 01:50:36 pm »

Hi,
taking advantage of DST compressed files support (http://yabb.jriver.com/interact/index.php?topic=72180.0) I'm considering converting my uncompressed dff files to DST compressed dff files.

This compression would permit to save a lot of storage but I have two problems:
1) The dff files (compressed or not) don't support tagging; someone in the feature requests suggested to use sidecar files for dff files tags; can you tell me if you are planning to implement this feature in the future?
2) I discovered the MC17&18 support DST compressed dff files extracted from sacd iso but don't support dff files extracted as DSD and then compressed as DST.
I tested the same two files with Foobar and I had no problem !!

Like I did in the other topic I provided a sample for these two files (take a look at your email Matt!).

Thank you in advance for your support!

Bye

Andrea

Matt · « **Reply #1 on:** September 23, 2012, 02:16:31 pm »

Thanks for the links. I'll download the files from work tomorrow, and follow-up a little later in the week.

rael71 · « **Reply #2 on:** September 23, 2012, 02:24:32 pm »

You're great!

Can you tell me anything about sidecar files for dff files tags?

Thank you!!

Bye

Andrea

Matt · « **Reply #3 on:** September 24, 2012, 01:15:54 pm »

Next build of v18:
Fixed: Some DFF files compressed with DST would not import.

I'm not sure about sidecars. We currently only use sidecars for video files. Another option would be to add an ID3v2 chunk to the DFF. That wouldn't be strictly following the standard, but it would also work fine and be harmless for software that doesn't support that chunk.

rael71 · « **Reply #4 on:** September 25, 2012, 04:13:34 am »

Thanks Matt!!!

About dff tagging, for me both solutions are fine if they work!

Thank you again.

Bye

Andrea

rael71 · « **Reply #5 on:** September 30, 2012, 05:49:14 am »

Hi,

I've tried the new build and it works perfectly with manually DST compressed files.

Any time plan for .dff files tagging?

Thank you!!
Bye

Andrea

ted_b · « **Reply #6 on:** September 30, 2012, 09:49:46 am »

DFF file tagging is a losing proposition, since diff headers don't accept IDsV2, etc. Sorry to be so black and white but what is wrong with simply converting to DSF? It's the only DSD format I will use, mainly due to great tagging support.

rael71 · « **Reply #7 on:** September 30, 2012, 11:43:12 am »

I know that tagging is not supported for dff files and for this reason I currently use dsf.
As I explained in my first topic the reason for using DST compressed dff files is saving of storage (the same file in dsf is 100 MB and in DST is 35-40MB).

I only asked if it's possible with a "trick" (es. sidecar files) to have file properties in library even without a true tagging.
If this isn't possible or if the team prefers not to develop this feature no problem, I will continue using DSF and probably I'll buy some more storage...

Bye

Andrea

ted_b · « **Reply #8 on:** September 30, 2012, 12:06:45 pm »

Oops, sorry, my bad. DSF doesn't compress using DST.

rael71 · « **Reply #9 on:** September 30, 2012, 12:38:57 pm »

Quote

Oops, sorry, my bad. DSF doesn't compress using DST.

Don't Worry..

Yeah that's the problem, Philips (dff) and Sony (dsf) have their own standard and DST compression is Philips' standard....

Bye

Andrea

rael71 · « **Reply #10 on:** January 25, 2013, 05:23:52 am »

Quote

I'm not sure about sidecars. We currently only use sidecars for video files. Another option would be to add an ID3v2 chunk to the DFF. That wouldn't be strictly following the standard, but it would also work fine and be harmless for software that doesn't support that chunk.

Please can you tell me if you plan to implement one of this option for .dff tagging in the future?
Just to know if I have to buy some more storage....

Thank you and bye

Andrea

Matt · « **Reply #11 on:** January 25, 2013, 10:18:50 am »

Quote from: rael71 on January 25, 2013, 05:23:52 am

Please can you tell me if you plan to implement one of this option for .dff tagging in the future?

Possibly in a future version, but not for MC18.

6233638 · « **Reply #12 on:** March 16, 2013, 03:17:11 pm »

I wasn't sure whether to create a new topic for this or not; I was wondering if there were any performance differences between .DSF and .DFF files due to the DST compression if you are converting to PCM? (I don't have a DSD capable DAC - at least not yet)

It doesn't seem to matter with 2 channel SACDs (so DSF is preferred as it can store metadata) but with multichannel SACD, there can be huge differences in size between the two formats - one disc I have is around 2GB when you extract as DFF files, and over 5GB when stored as DSF files - it takes much longer to extract as DSF as well.

I don't own that many SACDs anyway, so I suppose it doesn't matter in the end, but I was wondering if I'm better off extracting as DFF + Cue, or DSF and taking the hit on space. I'm sure you can probably convert between the two formats, but I haven't seen an easy way to do that.

sla · « **Reply #13 on:** March 16, 2013, 08:16:07 pm »

well there is a huge difference between DFF (DST compressed) and DFF (clean) or DSF in size, regular 2-channel DFF not compressed is around 2GB, compressed 800MB. also if ISO is multichannel and one is using only stereo we have around 4GB for ISO versus 800MB for 2-channel compressed DFF.

I moved from ISOs to DFF recently [with my collection of about 100 SACD I was getting close to filling my 512GB SSD...]

regarding CPU usage - I did not see that much of a difference between compressed and not compressed.

ALSO -> tagging no tagging - there is no problem with JRiver with DFF files. When you convert from ISO scarletbook usually names the tracks itself so now you only need to rename the folder: something like this:
\Artist - Year - Album\ and then inside the folder you have all the tracks already properly named from ISOs
01 - Name.dff
02 - Name.dff
Etc...
And now it is very easy to get this information imported to JRiver Library, you just use "import from file names" <or something like that in the library option>

6233638 · « **Reply #14 on:** March 17, 2013, 03:26:52 am »

I suppose it's true that not having metadata wouldn't be the end of the world as long as JRiver can store it in its own database or sidecar files; though I prefer to keep it inside the file where possible - but not at the expense of 3GB space!

It seems like DFF with DST compression might be the way to go rather than DSF for multichannel. (filesize was identical for two channel - but maybe my discs just weren't using compression on the two channel tracks?)

I have another question though - am I better off storing both the multichannel and stereo tracks, or should I just go with JRSS downmixing?
At some point in the future, I might move to multichannel, and who knows if working PS3s will even still be around to re-rip my discs. (I had two die on me before giving up on them and building the HTPC, and the only ones that can rip SACD are the original model)

Though it's looking less likely that I would move to multichannel to be honest - I just think stereo sounds better most of the time and while I haven't heard proper multichannel music, the surrounds mostly seem used for gimmicky effects in films, with all the dialogue going through the center channel. If I stick with stereo, I have more than three times the budget to spend on each individual speaker. (or I could spend less and still have better sound)

I was also wondering if the lowpass filter was adjustable. The Wiki states that MC18 is using a 30kHz filter with a 24dB/octave slope, but I thought the spec called for a 50kHz filter. (though I am unsure of its strength) I don't know if that was just based upon the limitations of 1999 hardware though.

Converting DSD to DXD (and then FLAC) shows that the noise seems to start around 60kHz, and there is still "audio" data above 40kHz.

Looking at a relatively recently released DSD-capable DAC, it has two filter options:

Quote from: http://www.auralic.com/download/flexible_filter_mode.pdf

In VEGA's filter design, we use IIR low pass filter at digital domain to control the stop‐band noise.
The ‐3dB cut‐off frequency of MODE 5 and MODE 6 are 70K and 50K with a general slope at 18dB/oct. The frequency response of MODE 5 and MODE 6 are shown in Figure 6.

But I suppose that assumes anything above 20kHz is even worthwhile anyway. (I'm not convinced that it is)

Matt · « **Reply #15 on:** March 17, 2013, 09:24:30 am »

Quote from: 6233638 on March 17, 2013, 03:26:52 am

I was also wondering if the lowpass filter was adjustable. The Wiki states that MC18 is using a 30kHz filter with a 24dB/octave slope, but I thought the spec called for a 50kHz filter. (though I am unsure of its strength) I don't know if that was just based upon the limitations of 1999 hardware though.

Options > Audio > Advanced > Configure input plug-in > JRiver DSD Plugin

6233638 · « **Reply #16 on:** March 17, 2013, 09:30:11 am »

Quote from: Matt on March 17, 2013, 09:24:30 am

Options > Audio > Advanced > Configure input plug-in > JRiver DSD Plugin

Great, thanks. I did a search for DSD in the options window, but it didn't bring that up.

kstuart · « **Reply #17 on:** March 17, 2013, 05:34:21 pm »

I seem to remember that DSF is stereo only...

ted_b · « **Reply #18 on:** March 17, 2013, 05:56:40 pm »

Quote from: kstuart on March 17, 2013, 05:34:21 pm

I seem to remember that DSF is stereo only...

Nope, I play DSF 5.1 multichannel daily,. with my stacked Mytek 3 DAC setup. But yes, the files are rather big.

kstuart · « **Reply #19 on:** March 17, 2013, 08:46:14 pm »

Quote from: ted_b on March 17, 2013, 05:56:40 pm

Nope, I play DSF 5.1 multichannel daily,. with my stacked Mytek 3 DAC setup. But yes, the files are rather big.

Then yet another bit of false information in Wikipedia:

" DSF is a stereo-only, simplified form of DFF, the format used for SACD mastering and 5.1-channel downloads. "

6233638 · « **Reply #20 on:** March 18, 2013, 01:51:09 am »

Interesting - perhaps DSF was only designed for stereo, and may only work with stereo tracks in an actual SACD player, but you can encode multichannel audio to it and software (at least JRiver) will read it anyway?

sacd_extract will definitely let you put multichannel audio into DSF files - but it seems like I should stick to DFF with multichannel. It's too bad DFF doesn't support metadata. I was impressed with the amount of data actually contained within the files, though sacd_extract isn't putting all the metadata it can read into the DSF tags, such as catalog #.

ted_b · « **Reply #21 on:** March 18, 2013, 07:14:56 am »

I love DSF and continue to use it for multichannel; storage is cheap.

sla · « **Reply #22 on:** March 19, 2013, 08:35:15 pm »

SACD was developed by SONY and Philips,

DSF is SONY way of writing DSD files and DFF is Philips,

DSF is not compressed, you can get files from SACD iso in both formats, DSF is not compressed. DFF may be compressed by DST or not.
[SONY, MFSL, SHSACD usually are not compressed...]

6233638 · « **Reply #23 on:** March 25, 2013, 09:33:33 am »

So far, all the SACDs I had gone through did not have any DST compression for the 2 channel tracks, and some used it with their multichannel tracks, so I had just been using DSF for 2ch as it's a lot more convenient being able to store metadata in the files.

However, I've just encountered a disc which uses DST compression on both the 2ch and 6ch tracks. With the 2 channel tracks, that is 2.45GB vs 0.85GB, which is a huge difference.

Are there any tools that will let you convert uncompressed DSF files to compressed DFF files? If they are not compressed on the disc, sacd_extract does not apply any compression to the DFF files. As I rip more of my SACDs, I'm just realising how much space they're going to take up.

And I was also wondering - is there any reason to keep the 2 channel tracks, or should I just store the multichannel tracks and use JRSS downmixing? (I've been keeping both so far, because I assume the mix is probably different)

I know that it's been suggested to just store the ISO, but I would rather extract the tracks to individual files.

sla · « **Reply #24 on:** March 25, 2013, 10:14:10 pm »

I actually only keep 2 channel dff. Yes the mix may be different for 2.0 and 5.1 but 5.1->mixed back to 2.0 should not sound as good as original 2.0 [even assuming that 5.1 mix is better].
keep 5.1 if you have 5.1 system and 3 Myteks 192 [= $4500 ,as this is the only setup that will allow to play 5.1 DSD]. there is several software solutions that will allow compressing with DST -> now I do not know if there is any free software available...
hope that helps.

6233638 · « **Reply #25 on:** March 26, 2013, 03:27:10 am »

You have a good point about only keeping stereo DSD files actually - I suppose if you're bitstreaming to a DSD DAC, you won't be able to downmix and must convert to PCM first, so stereo files would be better.

The only reason I'm keeping the 5.1 files for now is because maybe at some point in the future I might upgrade to a surround setup (even though it seems unlikely now) and at some point in the future, maybe AVRs will support DoP, rather than requiring three Myteks, and who knows if PS3s will still be around and working to re-rip all my SACDs again when that happens.

There's also the possibility that I could upgrade to a sound card which supports 3D/Virtual Surround with headphones, or that MediaCenter could be upgraded with better headphone support.

I was hoping that there would be a tool similar to sacd_extract to add DST compression to my files, but it sounds like I would need one of the various DSD workstations (Sonoma/Pyramix) which are probably very expensive.

sla · « **Reply #26 on:** March 28, 2013, 07:25:51 am »

I would keep ISO files somewhere... [I have 512GB SSD I use to play my music from]. In any way 2GB WD Passport in USB 3 mode is small (laptop drive) and relatively quiet and can be purchased for around 120-140?

6233638 · « **Reply #27 on:** March 29, 2013, 05:23:00 pm »

As a word of warning to anyone else; don't rename DFF files outside of MC18 and expect it to be handled nicely.

I had a few files that ended up with filename..dff as their name, because the [Name] field had a . in it, and I didn't want to figure out what expression I needed to avoid writing that when renaming files.

So I did what I usually do with my ALAC files to fix basic problems (e.g. the album has a : in it, and I want ; rather than the _ MC18 substitutes all invalid characters with) and renamed them inside explorer, then ran auto-import to have it pick up the file changes.

Big mistake: MC18 no longer saw those DFF files as the ones I had spent a while tagging and finding good cover art for, they were re-imported with only their filename and no metadata, with all previous entries removed. Renaming the files back to include the . again and re-running auto import did the same thing: new entries in the library that only had the filename and were stripped of all metadata, removing the old ones from the library.

Fortunately, there was one file that didn't end with a . in the name, so it did still have all the metadata and I was able to copy it to the other tracks (manually - I haven't figured out how to copy tags to other files) but it seems like that should not have happened.

Is there any way to have MC18 write this to an external file so that it can't happen again? This is the reason why I had been storing a copy of my album art inside the folder as folder.jpg, just in case something went wrong - a practice I stopped once I found out that MC18 won't rename directories if they contain files that are not imported in MC18's library. (I don't want those files imported, just in case something goes wrong inside MC and replaces all the cover art)

kstuart · « **Reply #28 on:** March 30, 2013, 12:48:12 pm »

I don't think these issues are particular to .dff files, I think they can happen with any imported files.

From reports here, the import/rename/move/fix-links processes are not 100% solid. (You can look through older threads for examples.)

So, what I do with all filename and filepath changes is:

* Uncheck "import in background"
* Delete from library
* Use smartlist that only consists of modifier "Limit Database To" "Removed" to delete those from the removed database
* Make filename and filepath changes using Windows Explorer or other program
* Run Auto-Import

INTERACT FORUM

Author Topic: DST compressed .dff files support (Read 18715 times)