So with my game stuff, Music is usually the biggest single element. As I do shareware games, Download size is a bit of an issue. I use Mods and I have been wondering if the size could be reduced by having a mod format that stored all of the sample data as oggs.
Support for something like this would be great for fmod and I figured it wouldn’t be too hard to do since fmod can already do oggs and mods.
I’m not too sure of the ideal way to implement this. One way I guess would be be to simply replace the sample data in a mod.
On loading FMOD could detect the ogg header and convert it to sample data conforming to the format specified by the sample header.
How hard would this be?
If FMODs could play such beasties we could write our own converters to turn mods into oggmods.
So what do you think?
- Lerc asked 14 years ago
You can theoreticly write code to load one of these into Fmod.
If you load the module as per normal then scan the xm file yourself you can use FMUSIC_SetSample to replace the samples with new ones
You can load the ogg files into memory with FSOUND_Load (using FSOUND_LOADMEMORY) You waould also have to set the looppoints for the sample to those specified in the module (remembering that the sample data might be decompressed at a different rate (possibly the default playback rate)).
All could be done currently in code using fmod calls (I think).
A better option would be for Brett to just do the ogg reading during the module load phase. I’ll probably send in a copy of my converter to firstname.lastname@example.org today and see what he makes of it.
That’s an interesting thought… even more interesting to say that I’ve thought of the very beast! The game that we are developing is going to use a freak XM format that uses OGG files as its samples. I’m just starting this so I don’t know where it’ll go, I just thought I’d let you know
I considered using FMUSIC_SetSample (I’ll do that as a fallback maybe).
I could make something that puts the oggs in easily enough (I think) . I had a quick look at the .xm format and looks simple enough. How similar are all of the other formats?
I’ll whip up a converter and see how it goes.
I really like this idea. Perhaps support for at-load decoding of OGG samples, and for at-first-use or realtime decoding could be added, to cut down on loadtimes? Decompressing 50 OGG samples at load can’t be very fast.
Oh, btw, Hello again Sastraxi! 8)
- Janus answered 14 years ago
Well the format I am using is to simply replace the sample data with an ogg file.
I’m using OggEnc to do encodeing just to make sure the format is ok.
Here’s what I plan. Nothing is set in stone so tell me if you hate it.
Righty the XM Sample header is unchanged. The data stored there is unchanged as well only the actual sample data gets changed.
22 Chars Sample Name
I am just replacing the Sample Data with the contents of an ogg file (exact output from oggenc). So there are in fact fewer than SampleLength bytes in the actual sample data because of compression. Upon reading the Ogg you have to either turn it into SampleLength Bytes or change the internal attributes of your mod player to deal with the ogg directly. (conversion sounds easier to me)
Initially I thought of Just placing the contents of OggEnc into the sample data on its own. I’m now tending towards placing a length DWord at the start of the sample data. This means to detect an encoded Ogg, one should check 4 bytes into the sample data for ‘oggS’.
The Length Dword will indicat the Length of the ogg not the Length of the Ogg plus the Length Dword itself.
Hopefully have the encoder done today. It extracts and encodes samples already, I just need to make the new format with the oggs put in.
Sounds good to me. But I think it would be better to cut down the size of the sample name to 18 and use the 4 bytes you get to store, before the sameple name, the “oggS” specification. If you did that then it would be to standards (and thus could be opened in things like modplug tracker, minus the samples).
The Length in the SampleHeader would still be wrong since it would refer to the decompressed size..
I could change it so that the First Dword of the encoded data contained the Length value from the original SampleHeader….
How about if the Encoder changes the SampleLength field to the size of the encoded data (Which would be the size of the Ogg plus 4) and you have to plug the Uncompressed size value into the sampleheader upon decode.
This would acheive the same net result without having to chop values off of the name.
I would mostly just recommend putting the file through a decoder if you wanted ito load it in a tracker though.
(encoder not finished yet, watching basketball ( New Zealand in semis of the world champs WooHoo! ))
Just a wee update. Encoder/Decoder done. I can encode an xm and then decode it again and play it.
Just tidying up user interface now.
As an idea of how well it works. this is how it goes on my main test mod.
1,705,600 Uncompressed xm
939,291 Zipped xm
358,323 Zipped Oggxm Quality 3
319,615 Zipped Oggxm Quality 2
275,288 Zipped Oggxm Quality 1
233,170 Zipped Oggxm Quality 0
Decoding the Quality 0 version back to an xm sounds fine to me (audiophiles may differ in opinion)
So basically if I were to create a quick player, it would:
Decode it to proper XM.
Load the XM.
Get Binary (ogg) data from the sample parts.
Decode to PCM.
Replace the samples with the decoded PCM data.
I think the best way would be to use the first. (save me some unnecessary coding ;)) hehe
Please login first to submit.