Import sample (*.ogg, *.mp3)

[Relabsoluness]

The modplug code should have a decompression routine. i don't know how complicated it would be to add compression.

There exists a NO_PACKING macro definition in OMPT code, which is on by default(defined in project properties), i.e. meaning that no packing is used. If the macro defition is removed and packing is enabled in the save function, some sort of compression of mono 8-bit samples seems to take place(but writing 16bit samples may need a fix after these modifications).

...the benefits of using OpenMPT is its speed and its small memory footprint. Compressing the samples will compromise one or both of these benefits.

Could you explain how saving samples compressed(which would anyway be optional) in files would hurt the memory footprint in practice? Especially given the current implementation where loading a 100 MB modulefile causes OMPT to temporarily allocate 200 MB.

[bvanoudtshoorn]

Could you explain how saving samples compressed(which would anyway be optional) in files would hurt the memory footprint in practice? Especially given the current implementation where loading 100 MB files causes OMPT to temporarily allocate 200 MB.

1. At startup: when you decompress a file, you generally need a fair bit of working space, depending on the compression method used.
2. Generally: if you decompress the files, you will probably have both a compressed and a decompressed version in memory (so that you can both save and play quickly).

At least, that's what I think the case would be... To be honest, I didn't realise that OMPT used that much space. Does this mean that plugins which use, say, 100MB also need around twice that much at startup? If so, it could explain some of the startup issues I have when I load tracks with > 2GB of samples in Kontakt...

[Relabsoluness]

1. At startup: when you decompress a file, you generally need a fair bit of working space, depending on the compression method used.

Indeed some working space is needed, but the need would be temporary and it's hard to imagine it would be significant (though I'm speaking without knowledge of the decompressing algorithms here).

2. Generally: if you decompress the files, you will probably have both a compressed and a decompressed version in memory (so that you can both save and play quickly).

ok, I didn't think the need, which doesn't seem vital, to have the compressed version in memory all the time.

Does this mean that plugins which use, say, 100MB also need around twice that much at startup?

I don't think so. The reason for the temporary 'double need' is that the module file is read to memory before actually reading the data.

If so, it could explain some of the startup issues I have when I load tracks with > 2GB of samples in Kontakt...

Isn't using > 2 GB of samples good enough reason for startup issues

[bvanoudtshoorn]

ok, I didn't think the need, which doesn't seem vital, to have the compressed version in memory all the time.

Well, I tend to save my files a lot. About every two to five minutes. If I did that, and had to recompress all of the samples each time, I can imagine that it would take a fair while, particularly given that you'll generally be wanting to use compressed samples on songs with fairly large sample sets. :/

Isn't using > 2 GB of samples good enough reason for startup issues

Yeah, I guess you're right.

[psishock]

Because I at least want modules that can be played with any other mod player as well? I know that you don't use samples and therefore don't care how you modules sound in XMplay or IT, but i do.

This is a very interesting point of view, we could discuss this issue on almost every feature upgrade =).
If compatibility would been the first point, we (almost) could end most of the developments, since some module players aren't developed anymore 2, so every "new" feature could hurt the availability of having the users latest song played on them. (i am aware of course that some of the features can be added without hurting the compatibility)
The best way handling this issue would be the choice again. We could choose while creating a new module, or saving the existing one, do we want compatibility mode or additional (new) features. You've seen it right by the way, i personally don't care much about compatibility, but respect those who do.

[locctr]

Decode it in realtime as a 'compressed sample' (*.ogg, *.mp3)

Safe system memory. (about 90%)

Resultly, enable load more sample.


PS. sorry about my short english   :oops:

[Saga Musix]

i was just wondering, we have an unrar lib and rar is a nice format to compress WAV samples ... so it would be a nice idea to use RAR samples, but AFAIK there's no free official sourcecode to build rar files... what about 7z? or we go straight for FLAC...

[Relabsoluness]

or we go straight for FLAC...

Sounds best. Have you looked the FLAC developers-page? Seems like that there are freely available libraries for encoding/decoding and examples how to use them.

[Saga Musix]

i haven't had a look at it (and i won't in the next few weeks, i guess, holidays are over and and class papers are coming now...), but this shouldn't be too hard to do: decode during loading and encode when saving. Of course, a new flag value has to be set then.

Another idea would be to rely on the MO3 format which has mp3/ogg/something lossless support, but there's no *official* documentation and I think this would kinda miss the point...

[Sam_Zen]

Yessss ! FLAC it is.. the near future. (there are some more lossless ones like APE)
The lossy compression like MP3 was developed in a time with low speed and bandwidth, to get a decent Inet-traffic.
These circumstances have been drastically improved, so MP3 or OGG will appear to have been a temporary solution soon.
So, if a new format should be implemented, I think it's better to look ahead for one, than to look back.
A FLAC makes a WAV about 50% of the filesize, which is still quite substantial.

Most of my tracks are published in the OGG format now, free to download. Because I don't consider it the original.
I compare it with a printed poster of an original painting.
I'm planning, as an experiment, to publish (maybe only on demand) a 'quality' version of a track in FLAC format.
So one gets the original WAV back, with the possibility to burn it on an audio-CD.
I would publish the FLAC in a 7-zip file. Not to make it smaller (remains the same), but than I can add things like cover-art.

[Saga Musix]

in the meantime, i've asked Ian for a library version of UNMO3 which would allow us to load modules packed with MO3. that's the first step to do.

[psishock]

FLAC it is.. the near future

but it's actually the present.
Renoise works with FLAC samples and does the job perfectly. =)

[Sam_Zen]

2 Jojo
MO3 would be a nice option too. It's more directly related to modules.

2 psishock
Yep, it's my present as well. Didn't know about Renoise. Great to hear that a well-known app is already using FLAC.

[Saga Musix]

Stay tuned.... MO3 support is coming. =)
About FLAC, OGG, MP3 and whatnot support, I don't think that we will do something about that in any other formats than MPTM, and since I brought up the suggestion to clone Renoise's module format, I'd also wait until any concrete things are decided.

[Rakib]

Sounds great!
I don't think implementing the mp3/ogg sample support isn't not really an issue anymore because limiting the filesize is not so relevant anymore because of bigger harddrives. Even though lossless ogg-format would nice.