How do you store DFF ( untagged ) files?

[Miska]

What's the ID3v2 blob? Google didn't help me ... Something like empty audio file with IDv3 tags?

 

I mean content of the ID3 tag, it is binary data encoded in certain way, see here:

Developer Information - ID3.org

 

I believe CPAN could have the needed tools for perl... (you were using perl if I understood correctly?)

Implementations - ID3.org

[One and a half]

4:45 long stereo track takes 2.4 seconds on my Linux desktop.

 

The converter is not optimized for maximum conversion speed, it would be probably possible to make it faster.

 

That what it should be, cause the only the header should change, the rest of the file remains unaltered. If the DFF to DSF conversion takes several minutes, it may go through a conversion process (like Jriver - currently).

[ted_b]

My regedit looks identical. Regardless, I tried something new and went to my start menu and used the global "default programs" setting app. Now it works as "SACD ISO to DSF per track". Thx

 

Question: why does the DFF to DSF portion of the process take more than a few seconds? Aren't we just changing headers? For me it takes half the time (which would lead some to think its going to the PCM world).

[bogi]

Basic answer appears at the 1st page of this thread, look at my easy experiment with hexadecimal file comparer: http://www.computeraudiophile.com/f11-software/how-do-you-store-dff-untagged-files-21780/#post352256

The same DSD content is coded differently in DFF and DSF files, so complete new file has to be written.

[bogi]

My regedit looks identical. Regardless, I tried something new and went to my start menu and used the global "default programs" setting app. Now it works as "SACD ISO to DSF per track". Thx

 

I could add your case in the PDF guide. Did you use the 1st (Set your default programs) or the 2nd option (Associate a file type or protocol with a program) in Default Programs?

[Miska]

That what it should be, cause the only the header should change, the rest of the file remains unaltered. If the DFF to DSF conversion takes several minutes, it may go through a conversion process (like Jriver - currently).

 

No, all the data needs to be reshuffled, because the data organization is completely different in the two formats...

 

So it needs to read all the source data, reshuffle it and write it out to another file. So for the 4:45 track it neads to read 200 MB from the disk, rearrange and write 200 MB to the disk. The time varies based on the HDD speed and the OS' caching capabilities. It is not so much speed optimized now and works on fairly small blocks of data (~15 ms). Code originates from my own internal testing tool, so speed was not the development criteria for it...

[Ran]

It took less than 10 seconds to convert a 380mb file on my Ubuntu machine.

[ted_b]

I could add your case in the PDF guide. Did you use the 1st (Set your default programs) or the 2nd option (Associate a file type or protocol with a program) in Default Programs?

 

2nd. Associate a file type

[ted_b]

It took less than 10 seconds to convert a 380mb file on my Ubuntu machine.

 

With Miska's code?

[Ran]

Yep.

[Miska]

I uploaded dff2dsf v.1.1.0 update here:

Signalyst

 

Now the same conversion takes 0.8 seconds on my old Linux desktop machine. I also added a check for DST compressed content so it should gracefully exit when such is discovered (with return value 2). However I don't have any DST compressed files to test with, so it's just a guess.

 

So conversion should be now faster. I did MD5 comparison of the resulting file to the previous version with identical results, but I would request others to also make sure I didn't introduce new bugs while making the conversion faster...

 

There is now also 32-bit Linux binary included.

[ted_b]

Miska, thanks. I updated it in the process flow in Bogi's setup and it runs considerably faster.

[One and a half]

No, all the data needs to be reshuffled, because the data organization is completely different in the two formats...

 

So it needs to read all the source data, reshuffle it and write it out to another file. So for the 4:45 track it neads to read 200 MB from the disk, rearrange and write 200 MB to the disk. The time varies based on the HDD speed and the OS' caching capabilities. It is not so much speed optimized now and works on fairly small blocks of data (~15 ms). Code originates from my own internal testing tool, so speed was not the development criteria for it...

 

OK, how does Audiogate 3 work on the conversion dff to dsf so quickly? For an album it takes maybe less than than 10s, in fact it takes more time to setup than execution.

[bogi]

Jussi, dff2dsf.exe still crashes in the case of DST input file. I sent a link to a DST file to your mail.

I sent you another mail related to the 'id3v2 blob' topic.

[Miska]

Jussi, dff2dsf.exe still crashes in the case of DST input file. I sent a link to a DST file to your mail.

I sent you another mail related to the 'id3v2 blob' topic.

 

Thanks! I'll check it out and also the ID3 tag. I'll try to put both fix for the crash and tag writing support and make a new build today.

[Miska]

OK, how does Audiogate 3 work on the conversion dff to dsf so quickly? For an album it takes maybe less than than 10s, in fact it takes more time to setup than execution.

 

I don't know. Did you try out the new version? I made the processing chunk 16x larger, now it's about 200 ms of data. I can bump it to 1 second or something like that if it feels there would be still an improvement in speed.

 

How much time it takes for you with the new version?

 

The 0.8 seconds it takes for me for the 200 MB track means there's already disk I/O exceeding 400 megabytes per second. On my Core i3 Windows laptop it took couple of seconds to convert the same file over a gigabit ethernet.

[bogi]

Update:

* some ISOs are not being extracted, but rather sent through in 1-2 seconds as if they were successful, with simply a cue file created. These same ISOs are successfully extracted via Jesus's GUI.

* some ISOs are creating nested subfolders (artist, then artist album). That is a pain but can be dealt with.

* some ISOs subfolders do not contain cue or text files when finished (even though dos prompt/messages are the same, of course).

 

In the case that album artist string or album title string is too long, I need to truncate it. In the version 1.0.0. I am creating output folder named "<album artist> - <album title>" under the folder, where SACD ISO is placed. I am thinking about using only <album title> as the output directory. <album artist> is probably part of the parent folder name, where ISO is placed. Truncation will be still necessary in special case, when <album title> is too long.

[ted_b]

My recommendation is to get the three of you entrepeneur/developers (Jesus R, Miska, Bogi) together and update Jesus's GUI to include the options to choose ISO->DFF->DSF. That way we have a mass/batch capability and easy GUI option buttons, rather than diving into code (config file, command lines, etc). Although I first wrote the SACD Ripping Guide for Dummies a few years ago to attract/educate a somewhat technical crowd that was willing to put up with hacked PS3's, the DSD-aware market is now grown large. Most of the later (non-early adopters) customers/users have no interest in diving into code. My $.02

 

Regardless, keep the improvements coming, cuz I am willing to dive a little.

[bogi]

My ISO2DSF is based on other usage ideas than a classical GUI app. I didn't create a GUI app because I don't want it for this task. I have always a file browser open, I am happy with my 2 click solution. The cfg file is not subject of frequent change. My tool can be incorporated into higher level scripts for a set of ISO files. The flexibility to start it from command line and the possibility to use it in higher level scripts are the main points for me. I have no intention to convert it to a classical GUI application.

 

If you want Jesus to change his tool, contact him. He can change his GUI easily to incorporate Miska's dff2dsf. He uses different way of implementation than I. I think for his tool it is suitable to use his way of implementation for the new option if he wishes to do it. We can discuss, anyone who wishes can contact me.

[ted_b]

Nevermind. I see they are two audiences. Thx

[bogi]

I incorporated Ted's findings in the new ISO2DSF version v1.1.0. You can download it here:

https://docs.google.com/uc?export=download&id=0B1IZPbDClIn6RlQtRW1nMFZ2V0E

Please read the updated PDF document.

 

Ted, your CUE sheets were helpful to address issues with very long metadata strings and untypical characters in them, which are not allowed in file/directory names. Thanks for testing.

 

Please let me know, if you have any issues, questions, suggestions.

[ted_b]

I sent you this email with the attachments mentioned here:

New version works almost flawlessly. All the troubling ISOs were fine. No nesting, no bypassing processing, etc. All metadata (txt files) were fine, regardless of whether cue files were turned on or off.

 

The only issue so far was with the Eric Bibb album called Rainbow People. The ISO named itself "Opus 3 - Rainbow People" and the title in JRiver (as an ISO, called SACD in JRIver parlance) is "Rainbow People" (with the quotes, see pic). But your program shows no title in the cue sheet (attached) and shows / as the title in the text file. I tried to see what the temp cue file looks like but it no longer shows (no big deal).

 

All in all, great work.

[bogi]

Miska just sent me corrected DFF2DSF. Both things work:

- detecting input DFF files in compressed DST format

- tagging the resulting DSF files using external file

 

It does mean, that in the next ISO2DSF version I will be able to generate tagged DSF files without the need to use external tagger like MP3TAG. That will again speed up processing.

 

Thanks, Miska!

[sjg]

Hi Miska, I am running ISO2DSF as a test and I believe that a step is missing from the instructions to copy the SACD_extract.exe file into the same folder where the other ISO2DSF files are.

 

Also, I could not get the context menu to work until I also copied the DFF2DSF.exe file from the win32 folder into the general folder location. .

 

I hope this is helpful. I am a good user of programs but no programmer. Thank You! Stephanie

[ted_b]

Stephanie,

I think you are a little confused due to the co-development paths. Miska initially offered a command level DFF2DSF program (which he continues to update) for all of us to convert DFF files to DSF. Then Bogi got involved and took that program and incorporated it into his ISO2DSF solution. He has packaged sacd_extract (Mr Wicked's google code) which does ISO extraction to DFF or DSF (we choose DFF in this example), DFF2DSF (Miska's code) to do DFF to DSF conversion, and the config files and utilities that allow context menus, cue file creation, etc.....all from one command.

 

Bogi delivers a nicely written PDF user guide in his download package, and in it he clearly states that sacd_extract needs to be in the same directory, etc (Miska's program does not need sacd_extract because it does not deal with that earlier step of extraction, only the heavy lifting of DFF to DSF).