I do not own a Squeezebox so I am not intimately familiar with all of its capabilities. However, I would think that you could save yourself the conversion and hard drive space by having MC send the original file and do any required conversion on the fly. Perhaps AndrewFG could chime in since he would know way more about this than me.
Squeezeboxes cannot play native DSD. If playing a file natively to a Squeezebox, the best format is probably AIF (because it is essentially the Squeezebox internal format and no additional transcoding or bit shifting is needed). But if playing to a Squeezebox via UPnP / DLNA, either via the Logitech plug-in or via Whitebear, then Flac is probably just as good, (LMS has to do a bit of transcoding, but the transfer requires less communications bandwidth).
Followed all instructions and conversion completed. The MC instructions say the output should be (Once you have PCM), 64bit @ 352.8 kHz for DSD.
The audio properties on the converted files show 24bit??? The file seems to sound ok? The converted file also shows 152,21 MB 72% compression, Original size 537MB, Sample rate 352.8 KHz, Bit Rate 16,934 (DVD), Encoder ibFlac 1.2.1 20070917, Audio Quality Perfect (lossless).
Is this correct or am I doing something wrong to get 24bit instead of 64 bit? Thanks for any help!
I don't think you are doing anything wrong at all.
But I do agree with you that the Wiki's statement about "64bit" is at least confusing if not totally wrong. The statement really means that when MC is converting from DSD to PCM it does its internal processing using the CPU's 64bit integer register operations, to ensure that any losses due to integer rounding are shifted down to a level many orders of magnitude below the level of human perception. Nevertheless once MC has done all of its conversion filtering and processing, it must then convert those internal 64bit integer values to something that can either 1) be saved in an audio file (e.g. Flac), or 2) streamed directly to a DAC. And in both cases 1) & 2) the highest possible resolution with today's technology is "only" 24bit.
In other words, all internal processing is done at 64bit inside the CPU, and only the last step converts from 64bit to 24bit. Of course, there might be an integer rounding error at this last step, but a) it is better than having integer rounding errors at all steps in the processing, and b) even a rounding error at 24bits is ~12dB below the threshold of human hearing.
I just converted a number of DSD files (originating from ripped SACDs) to 88.2/24 FLAC (for use with my Squeezeboxes) and I also found the resulting file was 8-10 db lower in volume than the original recording. I confirmed that I had not accidently checked normalize to 95% before encoding. Any other explanation?
Based on the above, the following is just my own theory...
Background: If the final output is 24bit, then when you create your CPU internal 64bit integer register value, you have 40bits of free room to play with. When doing integer arithmetic in a CPU you have to avoid a) low bit rounding errors, and b) high bit integer overflows. For the best accuracy concerning low bit rounding you would allocate all the 40 "spare" bits on the low order end of the register. But to avoid high bit integer overflows, you must allocate a few of the "spare" bits as headroom on the high order end of the register.
So my theory is that when MC does the initial conversion into internal 64bit register values, it applies 2..3 bits of (extra) headroom to avoid integer overruns, but that when it converts the internal 64bit register value for output to a 24bit file or DAC, it is perhaps not removing these -- no longer needed -- (extra) headroom bits. This would result in a volume reduction approximately of the order being observed. EDIT: and this would also mean that the DAC is getting only a 21..22 bit resolution signal instead of the full 24bits that it should be getting; thus nullifying any advantages that you may have gained by avoiding integer rounding errors in the first place...