Topic: mogg

[eggbird]

how about changing mo3 to mogg? (module with ogg vorbis samples). or, even cooler, add a function to BASS that allows it to decode the mo3 samples via an external stream, so that in theory support for ANY compression algorithm is possible.

but that ofcourse would be a problem for mo3 playoff through xmplay, or unmo3...

anyway, ogg's sound quality is imho quite superior to mp3's, and also has much better future perspectives because of all the opensourceness. ogg support in BASS and mo3 and xmplay would certainly rock.

(i know ogg support for bass or xmplay has been brought up some times already, but where streaming allows it to be solved for BASS, it doesn't solve the issue with xmplay or mo3)

eggbird

[Ian @ un4seen]

I was in the middle of adding OGG support to XMPlay a while ago, but kind of got side-tracked and haven't got round to finishing it

But I think that was probably a good thing actually

Because OGG is open-source, and therefore in constant development, it's probably best if I add support for OGG via a "plugin" based on the OGG SDK. That way it can stay up-to-date by simply replacing the OGG DLL(s), without having to update the BASS or XMPlay code everytime

I'm not sure how it'd work with "MOGG" though

[eggbird]

(sorry for the late reply)

i just saw that you put out bass 1.2 with proper ogg support, nice thing, this means that i can now actually use the bass test program to play any music file i have besides vintage shit with a program that i can store in my universitycomputer's 15mb homedirectory sizelimit without worrying about it! (before i had fmod for the ogg support and xmplay for the rest, which is ofcourse a big waste of space, them both being 200k in size =])

but anyway. sorry for being boring and all, but why would MOGG not work? i mean, if mo3 works than why not mogg? it should be possible using the same little ogg plugins that bass now has for xmplay in pretty much the same matter, and i can't understand why the mo3 encoder should be able to do mp3 but not ogg... i mean, the plugin idea is actually very nice, and quite well suited for a purpose as this, right?

the only problem i can think of is that mogg is probably an even uglier name than mo3. :)

ebd

[Ian @ un4seen]

In theory, MOGG would be a pretty simple extension of MO3, but I haven't done any tests yet to see how suitable the OGG format is. Most importantly, how well it maintains the sample "shape" and length.

I'll run some tests soon'ish

[eggbird]

okay, cool! i'm interested in whatever results you might get!

ebd

[Ian @ un4seen]

I've added OGG support to the MO3 format now, and done some testing... there's good news, and bad news

First the bad...

The current OGG encoder is only tuned for 44.1khz and 48khz sample rates, but that's not a big problem and will probably be addressed in future updates. Worse is that every OGG encoded samples has a large header (3.7k), so it's useless for small samples

Oh, and it also adds almost 200 bytes to the BASS.DLL size

Now the good...

OGG keeps the sample shape and length exceptionally well. I've only tested about 10 files so far, but I didn't hear a single click in them

[Dotpitch]

The current OGG encoder is only tuned for 44.1khz and 48khz sample rates, but that's not a big problem and will probably be addressed in future updates.

*yeah i know, that was more than 4 years ago, but i stumbled upon it now, so i'm reusing this thread

the lossless codec in mo3 makes files pretty small, but i wanted to see if oggenc could do better. the latest official oggenc (v1.0.2 from Xiph) is still only calibrated for 44.1 kHz, and i'm sure it's also able to do 22.05 kHz too . even worse, calibrating Lancers build (oggenc v2.6 20050709) results in no sample rates (which you can only notice using the commandline mo3enc, cause the gui just walks over it) and aoTuVs build (oggenc v2.6 aoTuVb4-1.1.1) simply crashes when i try to calibrate it. i'm using the same commandline settings for these encoders as for the regular oggenc and xmplay can play files encoded with these encoders, so i'm wondering what's going wrong...

[Ian @ un4seen]

*yeah i know, that was more than 4 years ago, but i stumbled upon it now, so i'm reusing this thread

the lossless codec in mo3 makes files pretty small, but i wanted to see if oggenc could do better. the latest official oggenc (v1.0.2 from Xiph) is still only calibrated for 44.1 kHz, and i'm sure it's also able to do 22.05 kHz too

The MO3 encoder can't detect what sample rates the OGG encoder is tuned for (OGGENC will accept pretty much any sample rate), so OGG samples were fixed to 44100hz as that's what was supported back then. But it probably is about time more supported rates were added - I'll add 16000/22050/32000 to the OGG sample rates in the next release. Note that'll probably produce slightly larger results, but you can increase the compression level to bring it back down

. even worse, calibrating Lancers build (oggenc v2.6 20050709) results in no sample rates (which you can only notice using the commandline mo3enc, cause the gui just walks over it) and aoTuVs build (oggenc v2.6 aoTuVb4-1.1.1) simply crashes when i try to calibrate it. i'm using the same commandline settings for these encoders as for the regular oggenc and xmplay can play files encoded with these encoders, so i'm wondering what's going wrong...

I've not tried "Lancers build", but it looks like "aoTuVs build" requires the input to have a ".wav" extension (guess it doesn't bother to check the WAVE header). I'll add that for the next release.

[lkj]

Please open-source MO3!