#75 Subsong index 0-based vs. 1-based

[Anonymous]

Thank you so much for this excellent plugin!

Per the change log, as of version 1.1.3 the subsong indices were changed from 0-based to 1-based, which may have had something to do with Wavpack compression and how metadata (possibly including embedded cue sheets) is handled in that situation. However, this breaks the ability of the foo_upnp server to stream DSD over a network, as it will always decode to PCM when it encounters a subsong > 0 situation. If there are no other incompatibilities involved, it would be nice to be able to select the file indexing basis depending on one's needs. This could also resolve other concerns about having to reset the entire library when updating the plugin.

Another possibility is to allow the DoP for Converter function to be invoked during decoding to PCM by the foo_upnp server. DSD files previously converted to WAV or FLAC with this option enabled appear to stream as DoP, although with the server detecting them as DSD files in their original format with a subsong index > 0, they are further decoded according to the sample rate in the Output (per device) settings. This is not ideal either, but as long as it happens only once, no race condition should result from it.

[Anonymous]

Naturally, the behavior described in the 2nd paragraph yesterday is not repeatable today. The foo_upnp server is not detecting DoP in the WAV or FLAC containers and is streaming them as if they were PCM. The DAC simply tries to decode this, and plays it back as mostly white noise. So either a mistake was made in checking this or there's more going on here than meets the eye. Furthermore, the SACD Decoder doesn't decode the DSD in these files for local playback either. Same files created with the "DoP for Converter" option checked, different results one day to the next. Very strange.

[Maxim V.Anisiutkin]

Wavpack decoder (which is part of the foo_input_sacd component) requires 1-based indexing scheme. So, 0-based is not possible any more. Have you tried 1.5.5-0 in interim folder? It should extract DoP from WAVs/FLACs.

[Anonymous]

Thanks for the response.

Encoding a dsf or dff file using the command line Wavpack encoder outputs a wv file with a 0-based subsong index, which is detected and decodes as DSD with version 1.5.5-0 of the SACD Decoder.

Admittedly, this system does not include a direct connection to a DSD-capable DAC, so as a test bed, it leaves a lot to be desired. Regardless of the settings, relying on the SACD Decoder to decimate the files to PCM before sending to the selected output, files converted with the "DoP for Converter" option only play as white noise.

That said, a network AV receiver on the LAN is able to play back up to DSD128, so the main objective is to be able to stream to it, preferably with foo_upnp. It'd also be nice to be able to use foobar2000's converter to compress DSD files to Wavpack with similar results to the command line encoder, but it's understandable how difficult that would be to accomplish since audio is handled internally as PCM.

Most of the possibilities available have been covered in creating and playing back files created with the "DoP for Converter" option checked. Formats tried include wav, flac (1.4.3) and wv (5.6.0). With encoder switches to use stdin vs. tempfile as input. With and without DSD Processor 1.3.0-2 as a DSP. With the "Samplerate" in the Output (per device) set to various values. This most certainly affects the results when "DoP for Converter" is unchecked, no matter the "Type" selected. Type=PCM vs. DSD were also tested (although this has no effect when "DoP for Converter" is not checked).

The resulting files were nearly the same size as the original in all "DoP for Converter" cases, with most of the variance appearing to be in the file or frame headers.

On the playback side, everything was white noise. Engaging the DSD Processor did not change that, neither as a DSP for local playback nor in the foo_upnp device profile settings (which forces PCM, unfortunately, so that was never going to work unless somehow the MIME type could be set accordingly and the renderer honored it). Different things appear to be happening internally depending on the selected output device. WASAPI exclusive and shared were tried, as well as FlexASIO via ASIO+DSD (the native ASIO drivers for this sound card do not work correctly). Use of the DSD Processor as a DSP module only muddied things further. Perhaps it would make more sense copying the console output and more thoroughly comparing results, but what's clear in all cases is that no matter how they're created, a method to both decode DoP PCM files to DSD and decimate them to PCM for output has yet to be found.

For streaming, both DLNA and OpenHome renderers were tried, as were foo_upnp, Hi-Fi Cast and BubbleUPnP controllers. The only thing that worked with the latest SACD Decoder were files originally loaded with SACD Decoder 1.1.2 with subsong=0. Even then, the foo_upnp controller wasn't setting the MIME type correctly, but the other 2 controllers did.

The 2nd paragraph in this feature request can be ignored. Mea culpa in not being more careful in how things were set up and applied. Switching back and forth between versions 1.1.2 and the latest SACD Decoders left previously loaded files in various states. Since then, every single file created either via the foobar2000 converter or individual command line encoders have a subsong index based on 0, and the only way possible to stream these correctly would be to either decode to the original format with subsong index=0 prior to streaming, or to stream DoP with a MIME type that is recognized and honored by the renderer to treat them as DSD.