optivorbis / optivorbis Goto Github PK

Hello! I've stumbled upon this program, and the first thing I thought is that it would be extremely handy if I could just point this application at a folder and have it optimize everything within it without having to manually input each file. I'm a barely tech literate sort of person so I don't really know how to write a fancy script that would do that for me automagically like what I've seen others do. If there was a setting to optimize and overwrite the original files without having to do it all manually, that would rock my socks off. It would be doubly awesome if I could just drag and drop files/folders on the executable and have it do all the magic without ever touching a command prompt, kind of like how PNGOUT does it!

optivorbis compares itself to jpegoptim and optipng, but it has one big difference: it seems to always generate a different file.

optivorbis file1.ogg file2.ogg
optivorbis file2.ogg file3.ogg
optivorbis file1.ogg file4.ogg

md5sum file2.ogg file3.ogg file4.ogg

All hashes are different (all sizes are equal).

jpegoptim and optipng detect if the file they are overwriting would have a bigger or equal size, and do not overwrite it.

It would be nice if optivorbis would create reproducible files (as in: same input, same output).

subj

During the development of OptiVorbis, I created a dataset of Ogg Vorbis files for testing and evaluating it, which is mentioned in the README. So far, this dataset has been sitting on my hard disk and on a digital medium submitted with my thesis documentation, neither of which are accessible to the wider community.

In the interest of making it easier to reproduce the results described and to facilitate further research by interested parties, I think it's a good idea to make the dataset public in a free, reliable, research-friendly, and long-term way.

My main concerns with this idea are as follows:

• There is no commercial file hosting service that I know of that fits the bill. Fortunately, I recently stumbled upon Zenodo, which is supported by EU institutions and seems quite suitable for this purpose, as it assigns a DOI to its uploads.
• Intellectual property: in any case, the dataset files can be traced back to their original Freesound submission, but that doesn't mean that their licensing is compatible with this kind of distribution.

Now that file hosting is no longer an issue, only the intellectual property concerns remain, so it's wise for me to at least write this issue so that I don't forget about it and work on it can get done. If anyone has expert knowledge about my intellectual property concerns, please feel free to comment and give your perspective.

This issue lists Renovate updates and detected dependencies. Read the Dependency Dashboard docs to learn more.

Other Branches

These updates are pending. To force PRs open, click the checkbox below.

• chore(deps): update mcr.microsoft.com/vscode/devcontainers/rust docker tag to v1

Open

These updates have all been created already. Click a checkbox below to force a retry/rebase of any.

• chore(deps): update dependency eslint to v9

Ignored or Blocked

These are blocked by an existing closed PR and will not be recreated unless you click a checkbox below.

• chore(deps): pin mcr.microsoft.com/vscode/devcontainers/rust docker tag to 42734a8

Detected dependencies

• Check this box to trigger a request for Renovate to run again on this repository

Currently, OptiVorbis implements Huffman tree operations using the ouroboros and bumpalo crates. This works fine, but profiling showed that walking through Huffman trees is a hot operation during optimization, responsible for most of the execution time. Therefore, as highlighted by Amdahl's law, optimizing the runtime of this operation is crucial to increase the overall performance of OptiVorbis.

One possible avenue of optimization is to use the indextree crate instead of the two previously mentioned. The basic idea is to use it to store indexes instead of pointers to children in the tree nodes, potentially making it easier for the Rust compiler to choose to use a more efficient base + index addressing mode in the emitted assembly instructions rather than resorting to dereferencing a generic reference. Even if this change does not improve performance, it would remove one dependency and likely simplify the code, which is welcome anyway.

Some basic benchmarks should be added to the codebase to assess the performance impact of this change.

Reason: completely static binaries built with musl may be slower than the ones linked against glibc.

Reference:

• https://andygrove.io/2020/05/why-musl-extremely-slow/
• https://www.reddit.com/r/rust/comments/oh2k8l/rust_musl_and_glibc_in_2021/
• rust-lang/rust#70108

At least, performance of glibc vs musl is worth checking out.