Mp3 Time!

Ok, it's time I suggest this! For Audio in SL, I would like to see this for audio, (wav, MP3!!!)

MP3s would save LL some bandwith, save on loading time, save user banwdwith, save TONES of server space, it would save a tone! Now instead of encoding at 8bit mono channel (43k\sec) we could record at like 128kpbs that only 16k\sec for pretty decent sound, in stereo too! I would love to see that, LL would need to make an MP3 decoder but what the hell, it would save tones more!

128kpbs (MP3) VS 8bit mono channel (WAV)

MP3 = better sound then then WAV
MP3 = 16k\sec to stream
WAV = 43k\sec to stream
MP3 = is about 2.5 times smaller

***MP3 = 128kbps WAV = 8bit mono channel

This is compaired to ok sound from the MPs to a really crappy sounding wav and the MP3 STILL smokes it. Do it VS 192kbps and a cd quality WAV. A full 80 minute 192kbps MP3 is about 115megs, while a full 80 minute CD WAV CD QUALITY is 700 megs! That's 6 times bigger, which means 6x more space, 6x more bandwith... etc.. you get the point.

SL with MP3s are my wish for 1.3

P.S. For those who are like well decoding mp3s is heavier on the CPU... I have a 1200mhz, when I don't run mp3s it's at 2%, when I run mp3s... 3%...

When you upload graphics to SL they are re-encoded and compressed in JPEG2000 format. Likewise, when you upload sounds they are re-encoded and compressed in Ogg Vorbis format. This is arguably superior to MP3 in both sound quality and compression. Additionally, using MP3 format would require hefty license fees to Fraunhofer-Gesellschaft which owns the rights to the format. Ogg Vorbis is open source I think.

As far as I can tell the only difference your initial WAV files will make is if they are stereo or mono. You select the Ogg Vorbis bitrate you want them re-encoded in when you upload them.

I could be mistaken, but I have been told by more than one person that the server converts our uploaded WAV files to Ogg format, which is what is streamed down to our clients.

If this truely is the case, then effectively, your idea has already been implemented =)

I see Julian beat me by a hair =)

BTW, I'm curious what sense would stereo make when directional audio is already implemented from point sources of sound?

Well you can be goofy and move the camera back and forth during key parts of the song for the stereo effect. Heh. (And no I dont actually do that) Pfft : P

Good question. In the real world we have directional sound obviously, and we can hear a difference between a boombox (point source) playing a stereo song vs. playing a mono song. A stereo sample in SL is like having two slightly different sounds playing from two point sources a short distance apart. A mono sample is like a single sound playing from a single point source. I could be completely full of it but it seems to make a difference.

Ah cool, I didn't know that our stuff got reconverted. So if I upload alot of sounds, it might take me a while to upload. But then SL converts it and streams it other users who can download it much faster because it has been compressed... correct?

It is actually compressed before it leaves your computer AFAIK.

I don't know about sound, but it's definitely not true with images. I accidently uploaded a BMP image instead of the TGA copy yesterday and it took two minutes =D

Unless you're using RLE compression on the TGA file, a BMP file can actually be smaller than the equivalent TGA: TGA files support transparency data, BMP files don't.

Once nice feature would be to convert whatever format or bitrate sound we upload to OGG Vorbis Format. Right now it has to be a plain, 44.1Khz WAV file with "standard" encoding. If we could just feed it some format, have it convert it (up-sample, down-sample, convert, etc), that would be a real time saver.

I have no access to the actual code but I was under the impression this was true for images as well as sounds. Images are converted to the jpeg2000 standard (a lossy compression that can handle alpha channels). There are a couple of possibilities:
- It could take longer to convert a bmp than a TGA (god knows why)
- The resultant image is not likely to be the exact same. It is possible that a TGA gets compressed with a different algorithm than a BMP, which could result in different sizes.

And maybe other less obvious reasons. Or a bug.

This could be an expensive can of worms. Different file formats have different licensing baggage associated with them. For example the .au format (owned by Sun), .aiff (Apple, I think), .mp3 (Fraunhofer-Gesellschaft), .gif (Compuserve), etc. Including the ability to deal with these formats over more "open" formats would require fees to be paid, often time very very big fees.

All that aside, I agree it would be great to have more flexibility. I'd love to be able to use a wider variety of sample rates and bit depths in the .wav format and add .png to available graphics formats.

There is no license fee to decode MP3, only to encode.

Also, the way it works now is fine with me! Changing this is low on the list IMO.

No license fee, yet. Look at what happened with the Unisys patent and gif -- they waited until the format got popular, then started trying to collect license fees for both encoding and decoding.

I don't think Compuserve is trying to get licensing fees for the .gif file format -- the format itself wasn't patented, only the compression method used, and the Unisys patent on LZW compression has finally expired.

This is a good point. Many licenses like this require an extra burden upon the company developing the software IF the code is distributed outside that company. Therefore, if they keep the code on the server, they don't have as many problems as if they distributed the compression code in the clients.

Another good argument for implementing the compression on the server side is that would make it easier for them to fix things if something has gone wrong or needs tweaking.

I agree with Hank, that it'd be nice if it'd accept different sampling rates (22k, 11k, 8k, etc). I usually run sounds through the windows sound recorder utility to upsample, but it seems like a waste of bandwidth to deliberately enlarge a file for transfer (assuming compression is server side).

That's a good point about server side compression, Kex. If compression happens on our end we upload a 10 second sample in .ogg format that's probably only a few kilobytes. If it's server side we could upload about 1.7MB (44.1, 16bit stereo). Ouch.

And while we're adding different sample rates, are we ever going to be able to upload samples longer than 10 seconds?