v1.2: Don't like CMD window forced closing, after execute "balrogg.exe" printing helps or (de)compress.

Thanks for a new tool. I've tested it a little. My Opus tests, while showing some result don't make it usable in real repacking - the gain is tiny, no solid mode support (yet?).

Test corpus: Wwise Opus converted to generic opus: 14440 files
Opus: 581718877 bytes
Ballroggs: 567165459 bytes

Since opus files don't have codebooks which could be stored once in a solid mode and where oggre does it's job good, with opus it won't work. And rn since ballrogg doesn't support solid mode, one can't expect big gain on a smaller files concatenated into one stream.

I also tested initial ballrogg v1.0 on vorbis files in single/solid mode. It compressed files fine in single mode, but with the same files concatenated it gave an error.

Will do more tests with fresh builds when I have time.
Unfortunately for repackers, Opus is already a very effective format, with it's range-coder near Shannon limit and space for improvement is really tiny.

FitGirl: Wow! Those OPUS files are so compact! 2.5% size reduction is really not much.
For you, what would be the "sweet pot", in Kaktor's words, where you would use it, for a Repack? 5% or 10% or more?

Doesn't SREP or "lzp:8mb:3:h22:d64mb" give minimal results either? (min. 1-2KB.)

_contextmodel: Do you have a rough idea of ​​what the realistic gain would be if there were a public recompressor for WMV/WMA or MPEG-1/2 videos? (For MPEG2, there is a packer called "oca_mpeg06", but it is too slow.) Can the 2-5-10 or upto MB/s speed be achieved for these cases, as with BinkPack? You don't include H264 in the target list?

Around 10% with a reasonable MT-speed would be nice. But I doubt it's achievable with Opus. It's REALLY very good lossy format.

As for using it instead of oggre in repacks, will wait until the format matures and gets a stable version. Since the developer is interested in that project, it looks like just a matter of time.

Fitgirl,

Thank you for your response.

> My Opus tests, while showing some result don't make it usable in real repacking - the gain is tiny, no solid mode support (yet?).

The gain is small as Opus files tend to be quite well compressed already, sadly. However, it remains within realm of possibilities, and does happen at a fine-ish performance cost.

> Since opus files don't have codebooks which could be stored once in a solid mode and where oggre does it's job good, with opus it won't work. And rn since ballrogg doesn't support solid mode, one can't expect big gain on a smaller files concatenated into one stream.
> I also tested initial ballrogg v1.0 on vorbis files in single/solid mode. It compressed files fine in single mode, but with the same files concatenated it gave an error.

I will look into implementing this.

> Will do more tests with fresh builds when I have time. Unfortunately for repackers, Opus is already a very effective format, with it's range-coder near Shannon limit and space for improvement is really tiny.

Indeed. I would say that Vorbis repacking is a slightly better selling point.

kj911, Fitgirl:

> _contextmodel: Do you have a rough idea of ​​what the realistic gain would be if there were a public recompressor for WMV/WMA or MPEG-1/2 videos? (For MPEG2, there is a packer called "oca_mpeg06", but it is too slow.) Can the 2-5-10 or upto MB/s speed be achieved for these cases, as with BinkPack? You don't include H264 in the target list?

I will think about it.

> As for using it instead of oggre in repacks, will wait until the format matures and gets a stable version. Since the developer is interested in that project, it looks like just a matter of time.

I will let you know when this happens.

I have released v1.4. Solid mode for Opus files is now supported.

Around 2 months ago, i started working on an ogg recompression tool myself,

Unfortunately i never finished it to the point that opus is supported because i found bad results and ended up with negative ratio at that time.

I will provide a test here with the capabilities of it.

and i also provided DLLs with header if you want to use this piece of code.

Source Code will be available in the future when i am done with it.


PS. If the author of balrogg can allow i will use it instead of mine .... i think its better in ratio.

Feel free to use my code for any purpose as long as the terms of the license (GNU GPLv3) are followed and authorship is clearly stated/preserved.

i was under the idea that this code was shared here didn't actually think you are the author.

now that we established that, i did some checking on the sample i provided yesterday.

well done on that 12.5% ratio!!!

balrogg/archiver_ogg_recomp tested from GTASA game "STREAMS" audio files? (Contains many OGGs.

Note: SAAT Tool, losslessly decompress and recreate the whole game archives from prepare better compression. My test in few years ago resulted avg. 1006-1008 million bytes. (Extracted OGGs, compresses it oggre+srep+lolz)

Finally found a sample on which balrogg will fail

^^
balrogg is working as expected. the ogg file is broken/truncated. page 0-28 is intact but
last page 29 (0x1D263) is flag 0, so atleast page 30 (or more) must be available. but it
truncates in page 29 with around 1700 bytes to finish it.

if you want you can use ffmpeg to re-mux it to process it with balrogg.
make sure to use `-c:a copy` in ffmpeg