When working on version 4.0.0 of Deffy I noticed Deffy writes a wrong sample data size for DFFs converted to DSF in one of the headers of the .DSF file. This had to do with some padding confusement on my part. That bug is fixed.
This incorrect value has no consequences for playing the DSF files. DACs do not seem to care about this value. That's also how this bug slipped through, since I never noticed anything negative in playback. However, if it does bother you - and if the file permits - Deffy can correct this value, so you don't have to redo your DFF to DSF conversions. I advise against using this option if you're unsure if the DSF was produced by Deffy.
Prior to version 4.5.0 Deffy always wrote files with 8-bits sample values, so if your DSF has a 1-bit sample value it wasn't produced by Deffy (if with version 4.5.0 or later, it doesn't contain this bug), and the correction option will not be available. Also the total file alignment needs to be correct (if not, there's bigger problems and Deffy won't attempt a correction). If there's any other issues than just the sample data size, correction is also not available.
If you are not bothered by this incorrect value you can just leave it as is. The .DSF files with incorrect sample data size will play without issues.
If you do want to correct your DSFs, you have to find out first if the DSF actually holds this wrong value (for sure if it was produced by Deffy 3.0.0 and older), so after loading your .DSF file(s) -
make sure you first click the 'do DSF files' button at the top -, click on the 'Validate DSF files' button.
But wait... doesn't 'Information' (that last column) claim the file is okay? Why the extra button? Wasn't it validated already?
Well, yes and no. Some information in the headers of a .DSF file is redundant. For instance, in the first chunk the total file size is stored. In the past, when DSF was invented and the specs created, this value was important (on a 16-bit or 32-bit operating system or embedded system in a DAC, you'd have to split a gigabyte file into smaller pieces, so one needed to know the size beforehand), but with our modern 64-bit operating systems (even on 32-bit Windows, files can be larger than 2GB) this information becomes redundant: we already know the size after loading the file.
So that first check, claiming the file is okay, just looks at the essentials.
The 'Validate' button - in contrast - checks every little bit of the headers and performs some additional calculations to see if they match the real thing. That's why I wrote earlier that this value we are about to correct is really no problem. It claims a certain size for a certain part of the file that can simply be calculated (without knowing that claimed size). That's also how I discovered that in the DFF to DSF conversion this value was wrong (not matching the real part). Now mind you, this value can be important when converting back to DFF (depending on the implementation). If the converter assumes these values are all correct and does not perform additional checks, things might go wrong when going from DSF back to DFF. Deffy does check this. Fool me once... so even a .DSF file with the wrong size set in the headers will convert properly (hence 'the file is okay').
So please note that validation that shows issues does NOT automatically mean the DSF file is corrupt or won't play properly. Most of the time these issues involve header information that is redundant and your DAC or software player won't care. The other way around is also true: validation checks the file's metadata, but it can't validate the content (the music bytes). So a DSF that produces hissing or distortions - if not caused by the structure of the file - will still pass as 'compliant'.
After startup, five .DSF files loaded... (version 4.0.0)
After clicking on the 'Validate DSF files' button, it now looks like this... (note that on a first try the log window might open automatically, with Deffy behind it... you can change that in Settings)...
Four files passed validation, but the fifth file has an issue, which is correctable by Deffy [see the 'Information' column]... (version 4.0.0)
If the log didn't open automatically or you closed it, you can open it with this button...
To open the log... (version 4.0.0)
For this example the log looks like this (all the files are presented, from top to bottom)...
The top of the log, showing the first file that passed... (version 4.0.0)
To get to the file with the problem we need to scroll down...
The last file in the log, showing the problem and indicating this file can be corrected... (version 4.0.0)
If you want to correct this .DSF file, select it in the list by clicking on it, so it is blue selected. If you have more than one file to correct you can use Shift or CTRL to multi select. You can safely select the 'Passed' files with it, they will not be touched.
The file with the issue is selected (blue) and the 'Correct selected DSF files' button is now enabled... (version 4.0.0)
If you click the 'Correct selected DSF files' button, Deffy will first establish if it has write permission on the folder the .DSF is located in. If so, it will proceed after a stern warning asking you if you made a backup copy? If you click 'No' Deffy won't proceed.
I opted for this method (in stead of writing a new file) because your .DSF file might already be indexed by music players. So best to directly correct the culprit. But to avoid mishaps you really should make a backup of these files before proceeding.
After clicking on the correction button...
The file with the issue is corrected [shows a green flag and see the 'Information' column]... (version 4.0.0)
Of course, anal as we are, we then want to make sure it also passes validation, so first click on the 'Reset list: all' button at the bottom and then click 'Validate DSF files' once more.
And here's the result if everything went according to plan:
The file with the issue now also passed validation... (version 4.0.0)