Skip to main content ↑ ↓

Notice

Please note that most of the software linked on this forum is likely to be safe to use. If you are unsure, feel free to ask in the relevant topics, or send a private message to an administrator or moderator. To help curb the problems of false positives, or in the event that you do find actual malware, you can contribute through the article linked here.
Topic: Recombining .wv+.wvc into a single .wv (Read 3653 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Recombining .wv+.wvc into a single .wv

Today i was reading the basswv decoder's API and noticed that decoding a WavPack with the optional correction file applied only happens if i decode Wavpack from the filesystem, i cannot supply a secondary input if i like to stream the .wv+.wvc combo over HTTP for example.

I wonder however if it's possible to combine the .wv and .wvc files into a single .wv stream by "merging" the two file stream? I'm affraid this can be only achieved by losslessly transcoding again to Wavpack without Hybrid encoding and this requires significant CPU power compared to a simple stream merging.

You might wonder why is this interesting. Imagine an audio server where you have your audio files in Wavpack hybrid compressed. For streaming over the internet, the lossy part is a good choice and a sync app could easily download these to a DAP or phone. However at home we have  the network bandwidth to stream to our devices in lossless. To overcome the single stream input a server side script or application could easily merge the two files into one on-the-fly. This could be even done by a Raspberry Pi.

Recombining .wv+.wvc into a single .wv

Reply #1 –
You are correct in that there is no way to “merge” the lossy and the correction files together without decoding and re-encoding. However, since we are (I assume) talking about real time streaming, the CPU load would not be more than a few percent on anything but the lowest powered device (you would not use any “extra” mode on the recode).

Of course, once you had decoded to PCM, it might make more sense to just stream that rather than re-encode to anything. I guess it depends on the client capabilities and the actual physical network (i.e. 802.11g or GbE, a switch I recently made at home that I will not regret).

Recombining .wv+.wvc into a single .wv

Reply #2 –
At home i have a low power Atom N270 based server which consumes only 15W with a 2.5" drive but it's CPU capabilities are limited. For example I've measured transcoding form CDDA FLAC to Musepack (because Musepack encoders and decoders are among the fastest) and it's encoding at 5x speeds. My quad core AMD does the same at 100x+ speeds. I don't think that say a Raspberry Pi is more powerful either in this manner. So by these low end machines clearly the simple file merging would be the best.

The decode and stream as PCM way is interesting though. I haven't though about that. However decoding is still have to be done at the resource limited server. CDDA PCM should be not an issue for any network to stream. I'm not working with higher than CDDA resolution audio.