Current Compatible Import sample file format
*.wav , *.raw, ...
support more file format *.ogg, *.mp3
:)
Perhaps support for DirectShow filters or something?
*.wav data is too heavy. :D
Quote from: "älskling"Perhaps support for DirectShow filters or something?
no...
I have a lot of sound data with *.ogg format file.
(*.wav data is too heavy :D )
I also use the *.ogg format for a lot of my sound data.
But that's valid for the result of a work, not for the single samples in a tracker module.
Of course it would be easy going, if ogg-samples could be imported.
But it's a wrong stage in the process. It would mean having twice a (destructive!) compression.
So I prefer to have original WAV files as a sample. Nothing heavy about that I think.
One could import a complete song of 3 minutes as a single sample, and OMPT can handle it.
And importing is not all.
Suppose you import an ogg-sample. It will be decompressed before using it, so in fact a WAV.
Now, when saving the work, the sample data will be embedded in the resulting file.
My first request in this matter would be to add the FLAC format to import, because it's non-destructive.
I'm totally against any form of destructive compression based sample usage =), every musician should aim for the highest sound quality as possible imo. ogg or mp3 is not the way, no matter that they are small. FLAC, as Sam mentioned is completely OK for the job. small and no quality loss.
Yep. The compression formats were way ago created because of the lack of download speed and bandwith on the Inet.
So it should be as small as possible. But it's better be regarded as a temporary solution to keep it efficient.
In the early days of my tracking I used 8kHz samples, but that was due to the limitations of the system. I had to.
Now, things are improved, and I can use a sample of 44kHz 16-bits to get good quality.
So it's not so far ahead that an album could be published on the Inet in the FLAC format to provide the original quality,
and it's up to the consumer to burn it on a conventional audio-disk.
If I'm not wrong, APE and the WV format have non-destructive properties as well.
Of course those non-destructive methods produce a bigger file than the ogg-mp3 ones. Because no data is lost.
A FLAC file is default about half of the original.
Getting back to the topic:
So, if you have a lot of ogg-samples, convert them to plain WAV files before using them as a sample.
Easy does it with Oggdrop (http://www.louigiverona.com/webarchive/samzen/download/oggdropxpd189.7z)
Quote from: "Sam_Zen"So, if you have a lot of ogg-samples, convert them to plain WAV files before using them as a sample.
I disagree Sam =), if the sample is in .ogg or .mp3, the destructions/quality losses are already happened. Converting them back to .wav will produce the same crippled sound quality but bigger filesize. He should try to search for the original .wav files, if he wants the quality.
This is a common mistake as i've seen, people are example downloading 128 or 192kbit mp3s from the net and converting them to 320kbit so that they get higher quality, but this way the quality will get even worse =).
So the lesson from that should be, that the lost sound data cannot "magically" come back, you can just downgrade the quality, it does not work backwards. Stick with the original .wav .flac or other loseless formats files.
OR... open the world of the VSTIs :D, and get every tiny control for your sound from 0. Samples are static, they sound exactly the same every time you play them, and you have fairly limited control over how they sound. VSTIs can be very dinamic, the sound can morph with every play, and as i said you have full control over the sound.
This should be the final step. =)
To add something to the original question:
Even if import support were made for compressed files, then there would be a stage where the input file was converted to a wav, meaning that the module will always be big. Using ogg's and mp3's as sample data inside the song just isn't going to happen, because with each save, you loose quality of the samples.
You'd be better of converting them to wave manually, load them in the song, and then delete the waves. That way you'd have what you want without it requiring an alteration to modplug.
2 psishock
I don't think we disagree. Quality losses have happened, no magical recovery of the original.
I'm just used to convert a compressed file first into a plain WAV before working with it.
Just as I first convert a JPG to BMP before doing a process of editing.
ooo, now i understand your side of view Sam and as you've said, from that point of view we completely agree. LP helped 2 with the comment, basically you've talked about the further quality lose. I wasn't had sample editing in my mind inside the tracker, but of course, once you edit something, it needs again to be saved on the destructive format and will lose quality again and again with every save. That should be prevented no matter what. =) (imo, if no editing happened, the sample should stay intact, shouldn't be saved every time when the whole module is saved.)
Also now that i'm thinking about it, if i'm not mistaken, the latest module formats are already compressed (zipped) formats, so once you've added the wav samples, they will take (much) lesser space, the result is like we're using something like FLAC or other compressed format already (except from import and export support part).
QuoteI wasn't had sample editing in my mind inside the tracker, but of course, once you edit something, it needs again to be saved on the destructive format and will lose quality again and again with every save.
If so, it would indeed lose quality again and again, but I'm not sure if that's the case.
During the session, a sample, edited or not, is in memory as a WAV. So if the tracker is saved as WAV, the sample stays in that format.
A reason why I never saved a tracker in the MP3 format, because that stage would mean the double compression.
Also because maybe I want to do some post-processing on the output.
Quotethe latest module formats are already compressed (zipped) formats
I'm not sure if they are 'already' compressed. But some formats can be zipped in their own format, which can be loaded again.
See the top line of the open-list (L). The old ModPlug player already could handle this (R).
(http://www.louigiverona.com/webarchive/samzen/modz/oopenlist.png) _______________ (http://www.louigiverona.com/webarchive/samzen/modz/openlist.png)
Quote from: "psishock"Also now that i'm thinking about it, if i'm not mistaken, the latest module formats are already compressed (zipped) formats, so once you've added the wav samples, they will take (much) lesser space, the result is like we're using something like FLAC or other compressed format already (except from import and export support part).
OpenMPT doesn't compress anything as far as I know, but it'll load zipped modules. Also, the zip format isn't all that effective when it comes to audio, so the compression results are pretty modest compared to something like FLAC.
About the loss of quality with saves that LPChip expressed concerns about, of course you need to save samples in a lossless format (inside the module) until it's finished. When it's ready for distribution, I don't see anything automatically wrong with using compressed (mp3, ogg or whatever) samples. It might not be the best idea for your latest masterpiece, but if you have 50 modules going to be used as background music for a game then it could save a lot of space. Other uses could be to add long vocal samples and still share the source files without having to upload 100 MB IT:s.
I agree that it's not the best idea to have your entire sample collection in a lossy format, but that doesn't mean it's a bad idea to allow users to import samples from lossy formats.
it would be nice if OpenMPT supported compressed .IT samples, though. :)
Do notice, that if you would be able to have samples in your song (say mo3), and you would import samples from that song, you would also get compression in several stages.
Perhaps its just best to buy a new harddisk. They're very cheap nowadays.
Quote from: "LPChip"Perhaps its just best to buy a new harddisk. They're very cheap nowadays."
*cough* Lets try not to miss the point here =)
We could also rent an orchestra for a few hours, to to record our samples in the possible best quality for us, but we're talking about program features/optimizations here.
well, as said, the first step to lossless compression would be compressed .it files. modplug can load them, but it saves them uncompressed.
Questioner reply :
If enable import *.ogg, *.mp3...
It's so convenient MIXING from another music.
Quotebut it saves them uncompressed
Maybe this is the crucial stage : saving the file. With lossless compression.
The ability to open a compressed file always can be solved by a converter first.
QuoteIt's so convenient mixing from another music.
It's not the main purpose of MPT to function as a mixer. It's a tool to compose something.
Quote from: "Jojo"well, as said, the first step to lossless compression would be compressed .it files. modplug can load them, but it saves them uncompressed.
I wonder how good a job it-compression does with sampledata for example compared to flac; any idea?
afaik it's some kind of ZIP compression, so it's not as good as flac.
Quote from: "url]http://www.users.on.net/~jtlim/ImpulseTracker/update.txt[/url]"] - IT215 file format saving. Note that this is an alternative compression
format and is often better, but not always. Public releases of IT214
Patch 1 and Patch 2 can read IT215 compressed files. There is also a
version of MikIT that can read IT215 compression.
The modplug code should have a decompression routine. i don't know how complicated it would be to add compression.
We could snach it from the Impulse Tracker code, it's already done there. ^_^
IT is still closed source.
implement any open source method? ::) FLAC would be perfect for the job imo, the other informations (beside the samples) from the module could be also zipped.
So, in the meantime, I like to point to an efficient bidirectional converter of WAV - FLAC : Flacdrop (http://www.louigiverona.com/webarchive/samzen/download/flacdrop120.7z)
Also, this feature could be linked with one of Skaven's topic, the "Revised IT Project (.ITP) functionality":
http://forum.openmpt.org/index.php?topic=2515.0
All the informations can remain in the module data, but samples could be referred to via relative paths (and be in FLAC format =), so the orientation and the work would be even more simpler. This way, the sample data could be (de)compressed separately and the other module data will stay zipped example. If a lot of songs are using the same samples over and over, this also can be a huge space saver.
(my own song folder takes about 6.3gig space, got about 900+ songs that are "uncompressed" and many of them are sharing the same sample data, in fact many of them are just variations of the same "theory", i just like to have them separated so i can more easily manage and search amongst them. Backuping example would be a lot lesser bother, if the whole folder would take much lesser space =)
I think that it's important to bear a couple of things in mind when dealing with compressed samples.
1. If you don't decompress them, OpenMPT might start to chug when there are lots playing simultaneously - a lot of on-the-fly decoding isn't that easy.
2. If you do decompress them, it's going to do two things:
a. Increase the load times for files *dramatically*;
b. Increase the memory footprint for each file, particularly at load time.
To my mind, the second of these two options is the preferred, but really, I have to agree with LPChip about getting a bigger hard-drive. It sounds facetious, I know, but the fact of the matter is that one of the benefits of using OpenMPT is its speed and its small memory footprint. Compressing the samples will compromise one or both of these benefits.
Of course, I use Kontakt for all my sample playback, so each track I write is only about 250KB in size. I should point out that Kontakt doesn't compress its samples at all...
Barry, using the compressed samples while working on the music is out of option imo. I don't mind if the loading speed would increase, like the memory usage also. Thats a normal, in fact i would very much prefer all my samples to be uncompressed and stored in memory after load, while i'm working, for the best speed.
Bare in mind that all these compressions would be a -choice- for people who will have benefits from it, and don't mind the "negative" sides of the process, not forced to every user of course.
I have 2gigs of memory and around 800gigs hdd space, fairly fast processor, so the space requirements does not bother me much also, but if i'm talking about backing up, song/sample management, it would be more better if they would use a lot lesser space. I'm not using any VST sampler, but the OMPT's own. If that would be the case, maybe i would see the situation differently.
Quote from: "psishock"implement any open source method? ::)
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.
Quote from: "Jojo"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).
Quote from: "bvanoudtshoorn"...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.
Quote from: "Relabsoluness"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...
Quote from: "bvanoudtshoorn"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).
Quote from: "bvanoudtshoorn"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.
Quote from: "bvanoudtshoorn"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.
Quote from: "bvanoudtshoorn"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 :)
Quote from: "Relabsoluness"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. :/
Quote from: "Relabsoluness"Isn't using > 2 GB of samples good enough reason for startup issues :)
Yeah, I guess you're right. :D
Quote from: "Jojo"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.
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:
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? :D or we go straight for FLAC...
Quote from: "Jojo"or we go straight for FLAC...
Sounds best. Have you looked the FLAC developers (http://flac.sourceforge.net/developers.html)-page? Seems like that there are freely available libraries for encoding/decoding and examples how to use them.
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...
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.
in the meantime, i've asked Ian (http://www.un4seen.com/forum/?topic=9092.0) for a library version of UNMO3 which would allow us to load modules packed with MO3. that's the first step to do.
Quote from: "Sam_Zen"FLAC it is.. the near future
but it's actually the present. :D
Renoise works with FLAC samples and does the job perfectly. =)
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.
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.
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.
mp3 import support would be greatly appreciated. All I want to do is not have to save my files outside the application as wavs and since I downloaded a whole whack of mp3 samples that I want to use despite the quality they have already lost and I am having trouble finding something to convert them to wav for free and on mass and I frankly dont see why I should have to. Why cant there be a simple mp3 decoder built into the program to import mp3s into modplug and then convert them to whatever samples are used in the format you are using by stopping by wav along the way(if they have to). I dont care about the filesize of my .IT I can buy bigger hdds and I'm planning on buying a terrabite soon, but I live in South Africa, where people are constantly overcharged for minimal bandwidth. so downloads of big wavs are a problem and I dont want to buy any of the commercial versions of the mass converters.
what I'm trying to say is there must be some open source mp3/ogg/etc conversion software out there that you can link to codecs and then intergrate into modplug so that anything of that format can be imported into modplug straight from the format as if it was a wav.
Another awesome feature would be a record-to-new-sample button and options in the general tab or player dropdown that way bits of songs would be instantly integrateable into new songs(when you got multiple songs open and set at the same timing you could bring in features from other songs as pure samples without having to record it as an external wav).
anyways - these are probably only going to piss you guys off, but I am really desperate for the mp3 one unless you guys can help me find a free and relyable mass mp3 converter.
For the time being, you could mass-render MP3 files to WAV by using f.e. XMPlay - I do that sometimes.
Sorry Jojo, but XMPlay is a player, not directly a converter (I spend some time before finding that option).
For batch conversion of soundfiles better use WinLame (http://www.louigiverona.com/webarchive/samzen/download/winlame.7z).
The list with compatible sound formats can be found here (http://www.louigiverona.com/webarchive/samzen/download/winlame.txt)
By the way, Rakib, the OGG format is not lossless afaik.
Quote from: "Jojo"For the time being, you could mass-render MP3 files to WAV by using f.e. XMPlay - I do that sometimes.
Thanks, downloaded it, not sure why the last batch didnt work in modplug, but going to try again soon... 1900 something breakbeats and drum shots will be mine to work with soon :)
I should download more
btw, I'm sure I used to use an old version of xmplay back in the day to play my its - the question is how well has it kept up with open modplug - I should test a song :?
I think it'll be crap
Quote from: "Sam_Zen"
For batch conversion of soundfiles better use WinLame (http://www.louigiverona.com/webarchive/samzen/download/winlame.7z).
The list with compatible sound formats can be found here (http://www.louigiverona.com/webarchive/samzen/download/winlame.txt)
getting this one too
um, whats a 7z file? I'm downloading it somewhere else
QuoteSorry Jojo, but XMPlay is a player, not directly a converter (I spend some time before finding that option).
I know what I'm talking about, thank you. One can batch-convert *anything* (even modules) to WAV/OGG/MP3 with XMPlay in light-speed, no need for specifc tools for every format anymore.
Another option that i'd do, is drag and drop .ogg samples into Winamp and use the function of 'Send to:>>Format Converter' (Encoding format: WAV Encoder) via right-click in the desired/selected samples.
In the meantime, support for MP1/MP2/MP3 import has been added through libmpg-123: http://wiki.openmpt.org/Manual:_Samples#File_Toolbar
Great..another reason to update...
Always afraid my (keyboard/vst)settings get f**cked up again when doing so..
"Again"? OpenMPT won't touch your keyboard config when upgrading (unless you uninstall it and choose to remove your current config).
Well not to talk bad about this great product but in the very early openmpt versions, when I installed a newer version a new folder was created and I didn't know about the keyboard mapping file...
I also had to add all my vst's to the plugin manager again. That has been solved now by the scan for plugins option.
Most of the time I only updated after a windows XP crash/reinstall and was too lazy to get to the backup files... don't take it as a critique...
No offense, but these problems have been gone loooong ago. OpenMPT uses %APPDATA% for storing program settings by default.
Great. I just bought a new system, so will try it out :)
Support for MediaFoundation codecs has been added in OpenMPT 1.25, so on Windows 7 and newer, you can now load a great bunch of more formats as samples.
Quote from: Saga Musix on August 13, 2015, 18:25:26
Support for MediaFoundation codecs has been added in OpenMPT 1.25, so on Windows 7 and newer, you can now load a great bunch of more formats as samples.
Thank you very much, I have been noticing this and loving it!