Import sample (*.ogg, *.mp3)

[locctr]

Current Compatible Import sample file format
*.wav , *.raw, ...

support more file format *.ogg, *.mp3

[älskling]

Perhaps support for DirectShow filters or something?

[locctr]

*.wav data is too heavy.  

[locctr]

Perhaps support for DirectShow filters or something?

no...

I have a lot of sound data with *.ogg format file.

(*.wav data is too heavy   )

[Sam_Zen]

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.

[psishock]

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.

[Sam_Zen]

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

[psishock]

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 , 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. =)

[LPChip]

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.

[Sam_Zen]

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.

[psishock]

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).

[Sam_Zen]

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.

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.

the 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).

   _______________                                        

[älskling]

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.

[Saga Musix]

it would be nice if OpenMPT supported compressed .IT samples, though.

[LPChip]

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.