LossyWAV Sample

[RyanBram]

Hi, OpenMPT community.
I have two questions related to LossyWAV (or LossyFLAC) support in creating module format.

• Is it possible using LossyWAV as sound samples for reducing IT file size in OpenMPT?
• 
  Does currently OpenMPT provide a feature to automatically compress all sample using LossyWAV or LossyFLAC?

Regards.

[Saga Musix]

Is it possible using LossyWAV as sound samples for reducing IT file size in OpenMPT?

I did a quick (non-representative) test and IT compression does not seem to profit from lossyWAV's approach. It doesn't have a "wasted bits" feature like FLAC does.
The only way you can profit from it is by using external FLAC samples.

Does currently OpenMPT provide a feature to automatically compress all sample using LossyWAV or LossyFLAC?

No, but it can easily be automated using a batch file.

[RyanBram]

No, but it can easily be automated using a batch file.

Hi, Jojo.
Sorry for long reply. How to use batch file for automate the process of compressing impulse tracker samples using LossyFLAC?
Which or where executable I need for doing the job?

Sorry for any inconvenience.

[Saga Musix]

A rather simple batch file would look somewhat like this. First you'd save all samples (shift-click the save button in the sample editor) and put them in the same directory as lossyWAV.exe.

Code Select Expand

@echo off
cls
for /R %%F in (*.wav) do (
lossyWAV "%%F"
)

Then you'll get a set of new WAV files which you can load into your module. But as said, it's only really relevant when using external FLAC samples - IT sample compression cannot really benefit from lossyWAV, and in particular 8-bit samples do never profit from lossyWAV at all.

[RyanBram]

Ok, I got it.
Although the process is very simple, but it'll take some time if we want to compress hundreds of IT samples using LossyFLAC.
Do you mind if I create feature request in issue tracker for providing LossyFLAC sample compression option in OpenMPT (even though it may be your low priority)?

[Saga Musix]

I don't mind if it's on the issue tracker but I can directly tell you that I will not implement it because - and I say this for the third time now - IT samples do not profit from it.
Retrofitting hundreds of existing modules to take up potentially 10% less space is kinda backwards when hard disks are constantly growing...
As said, the only point at which you can really profit from this tool is when using external FLAC samples, and in that case you don't need any OpenMPT integration because you can simply let lossyWAV process all the externally stored FLAC samples. You'd need a few more calls in the batch file (to convert FLAC to WAV, run lossyWAV, rename the .lossy.wav files back and convert back to FLAC), all of which should be doable in PowerShell if not the regular Windows shell. But that is nothing that will ever be part of OpenMPT, because it's not part of what OpenMPT is supposed to do.

[RyanBram]

... and I say this for the third time now - IT samples do not profit from it.

Ok, sorry for making you said that three times 
I just didn't recognize them before, because you said that I can use LossyWAV for creating LossyFLACsamples. I just though that I can importing it back into my IT files to make it smaller. I understood now even though I can import LossyFLAC or even MP3 samples in OpenMPT, it will be converted back to RAW PCM, because it is the only valid samples for IT, isn't it.

Retrofitting hundreds of existing modules to take up potentially 10% less space is kinda backwards when hard disks are constantly growing...

Then there is no point MO3 format to exist or supporting it in OpenMPT, isn't it? This kind of format must be exist for some reason. Effort for creating small file size never extinct until today. Zopfli, PNGQuant, MozJPEG, Opus, etc are proofs that people still demanding for smaller file size and saying that as a backwards is irrelevant.

Thanks for answering my question as beginner in tracker music creation.

Regards

[Saga Musix]

I'm not saying that compressing files is irrelevant in general, just that if you already have a large bulk of modules, retrofitting them to use compression doesn't make much sense - partly because clearly you were able to store all of them in the past, so you will be more than capable in the future to store them, and the other part is the archivist speaking in me that original projects, once considered done, should not be touched and modified anymore.
If you want to compress your modules, it makes more sense to put them into general-purpose compression containers such as zip or 7z. OpenMPT can directly open modules from ZIP and RAR archives.
And in general, things like MO3, PNGQuant, etc. are supposed to be used as the final production step - not during production, because (at least some of them) they will continously degrade your material, e.g. MP3 compression on samples. That's the main reason why there will e.g. never be MO3 support in OpenMPT. It is very much a lossy format, even changing the pattern data, so it does not make sense to utilize it during proudction - only afterwards, if you want to use it e.g. in a game project.
Things like PNGQuant also have a different reason for existence - namely optimizing the daily bandwidth consumption of a website by optimizing the size of embedded pictures. It's not a tool you would generally use for your personal PNG collection.

[RyanBram]

... so it does not make sense to utilize it during production - only afterwards, if you want to use it e.g. in a game project.

You got the point. I am asking here because I want to make the final product. I want to use OpenMPT for creating (or editing) some module format and hopefully can get smaller IT file size. I heard about LossyWAV in this forum and hopefully it will help my intention, but found it not really help.
MO3 is my last hope, but BASS license is too expensive for single developer as me and it seems you don't have interest to implement it natively in OpenMPT or libopenmpt (although I don't know your reason for including unmo3.dll in OpenMPT installation). I prefer (if possible) to donate my money to OpenMPT project to support Mo3 instead of paying hundreds of dollars to single developer. Because it will also benefit to others as well. As additional, you absolutely already know that Mo3 also support lossless compression which means that supporting it in OpenMPT still not contradict with your principal as someone who have strong sense in lossless compression.

Regards.

[Saga Musix]

MO3 is my last hope, but BASS license is too expensive for single developer as me and it seems you don't have interest to implement it natively in OpenMPT or libopenmpt (although I don't know your reason for including unmo3.dll in OpenMPT installation).

There will probably maybe be built-in native mo3 support in OpenMPT/libopenmpt one day, but that's a very low-priority feature - given that unmo3 can already do the same thing and the complexity of creating an entirely new mo3 decoder from scratch.

you absolutely already know that Mo3 also support lossless compression which means that supporting it in OpenMPT still not contradict with your principal as someone who have strong sense in lossless compression.

As said, even when using lossless compression it still uses a "lossy" (or rather transformative) pattern compression scheme, meaning that patterns will look different from what they originally looked like in OpenMPT. MO3 can only be the last step of a production and it's not a step that belong into OpenMPT.

[RyanBram]

There will probably maybe be built-in native mo3 support in OpenMPT/libopenmpt one day, but that's a very low-priority feature

I am glad to hear that and don't mind to wait no matter how long it will be, because "low-priority" is better than "never".

- given that unmo3 can already do the same thing and the complexity of creating an entirely new mo3 decoder from scratch.

I tried to compare the lossless Mo3 with compressed IT using 7zip with LZMA Ultra. The result is the size of both are almost identical, given the fact that LZMA is a "true" lossless compressor. Unfortunately, currently OpenMPT only support "ZIP with DEFLATE" and "RAR"  and not ZIP or 7z with LZMA compression.

Maybe it is just a stupid idea, but compressing IT using LZMA and allowing Vorbis or LossyFLAC sample to be used in IT format (or MPTM) specification will resulting new module format similar with Mo3. It may be "easier" for programmer like you than creating an entirely new Mo3 decoder from scratch.

Regards.

[Saga Musix]

Given that you are talking about MO3's license fees I assume you want to use this technology in a game - in which case OpenMPT's zip/rar functionality would be useless anyway because it's a pure convenience feature for the tracker users; libopenmpt does not support it at all (there's no reason why it should support non-module format containers). You would have to add your own zip code anyway, at which point you can just add LZMA code just as well. That is completely independent of whatever compression scheme libopenmpt may or may not ever support.