You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Simply put, have WavPack as an exportable format, at least the lossless variant of the format.
The main thing is that WAV files are the only format that currently support 32bit floating point (though, as previously stated with issue #17, it might be slightly bugged) but WAV files only support files up to 4GB (which is a limit I've run into when working with longer, high sample rate files)—WavPack files however are very much not limited to 4GB and also support 32bit floating point.
It may be worth noting that, unlike formats like FLAC which are designed with a simple single value for how compressed a file should be with the trade-off of higher CPU usage (only really a concern for old sub-GHz CPUs), WavPack has not only a similar sort of "compression vs speed" value but also an "additional processing* value which can be used to compress the file even farther but only impacts the encode speed and not decode speed.
Now WavPack also supports hybrid-lossy, but this was never something that really "caught on" for a multitude of reasons, so I question if it'd even be worth spending the time and effort to make the software and its interface be able to handle encoding into WavPack's hybrid-lossy mode rather than just only supporting lossless WavPack.
The text was updated successfully, but these errors were encountered:
Simply put, have WavPack as an exportable format, at least the lossless variant of the format.
The main thing is that WAV files are the only format that currently support 32bit floating point (though, as previously stated with issue #17, it might be slightly bugged) but WAV files only support files up to 4GB (which is a limit I've run into when working with longer, high sample rate files)—WavPack files however are very much not limited to 4GB and also support 32bit floating point.
It may be worth noting that, unlike formats like FLAC which are designed with a simple single value for how compressed a file should be with the trade-off of higher CPU usage (only really a concern for old sub-GHz CPUs), WavPack has not only a similar sort of "compression vs speed" value but also an "additional processing* value which can be used to compress the file even farther but only impacts the encode speed and not decode speed.
Now WavPack also supports hybrid-lossy, but this was never something that really "caught on" for a multitude of reasons, so I question if it'd even be worth spending the time and effort to make the software and its interface be able to handle encoding into WavPack's hybrid-lossy mode rather than just only supporting lossless WavPack.
The text was updated successfully, but these errors were encountered: