Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Wave file audio compression #86

Open
schnaader opened this issue Sep 19, 2018 · 5 comments
Open

Wave file audio compression #86

schnaader opened this issue Sep 19, 2018 · 5 comments

Comments

@schnaader
Copy link
Owner

Currently wave files (.wav) aren't detected or processed. LZMA filters can help for 16-bit or 16-bit stereo audio files, but this doesn't work for embedded files. The lossless audio compressor wavpack can be used to compress audio data in this case and achieves much better ratios.

@schnaader schnaader self-assigned this Sep 19, 2018
@schnaader schnaader added this to the Precomp v0.5 milestone Sep 19, 2018
@andrew-epstein
Copy link

So, this issue involves two parts, right? (a). Detection of .wav files, and then (b). Compression of .wav files. It sounds like wavpack can be used for (b), but does it help us with (a)?

Also, if I am understanding this correctly, that means that the output stream will be partially compressed with LZMA, and partially compressed with wavpack. Is that okay? Does the .pcf format have support for that?

@schnaader
Copy link
Owner Author

schnaader commented Mar 1, 2019

There's some rudimental parsing code in wavpack, but I don't know if I'll use it yet. Luckily, part (a) is not very complicated as RIFF WAVE is easy to parse (although there's some ambiguousness, e.g. in the order of chunks). My current plan is to do the default first (WAVE-PCM), a bit of additional verification and to check additional nice-to-haves in later versions. I already have a proof-of-concept project for (b), so the implementation of this isn't as far away as it might seem.

The output stream situation is similar for JPG streams (packJPG) and zLib streams (preflate) - these both use an arithmetic coder, so their output is compressed. LZMA receives everything as one big output stream without knowing these details. That's not optimal since the compressed output will most likely get a bit larger. On the other hand, this gives LZMA the chance to de-duplicate in case of identical compressed output.

@M-Gonzalo
Copy link

@schnaader Any news on this?

@schnaader
Copy link
Owner Author

I'll start a branch where I will integrate my proof-of-concept in March.

@M-Gonzalo
Copy link

Thanks! Looking forward to it

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants