Ogg vs Caf for audio

Are these values milliseconds and is this SIO2 v1.3? If so: wow, the loading time has then massively increased in 1.3. For a 1.5 MiB OGG I was waiting ca. 20 seconds on the iPod (instead of 200ms here), that's why I decided do kick all sound/video-relevant stuff from the source and go for native Apple APIs instead. Good job, sio2interactive!

Best,
Matt

The numbers are seconds and it is not the 1.3 version. I havent gotten around to changing 1.3 and redoing the tests. For 1.2, caf is so much faster its not even close, as you can see.

With CAF's being so much faster than OGG's I am going to start on the journey to remove the dependency on the AudioToolbox.framework so that we can get this integrated into SIO2. All that remains to be done is a header parser for the CAF file so that the type/frequency/etc can be parsed out and the actual audio data can be grabbed. If anyone has code to parse a CAF header feel free to post it, otherwise I will start on this in the next few days.

I would be more than happy to be able to integrate it as long as there's no dependency with the AudioToolbox... However I would like to know which program let you edit / convert to .caf... cuz Audacity doesn't support it...

Cheers,

There is a commandline program called afconvert for conversion to either uncompressed or compressed caf files.

Uncompressed:

Code:

/usr/bin/afconvert -f caff -d LEI16 {INPUT} {OUTPUT}

Compressed:

Code:

usr/bin/afconvert -f caff -d ima4 {INPUT} {OUTPUT}

There are some programs that convert to caf as well but I have not used them. Two are: Max and Amadeus Pro.

I just noticed that the beta of Audacity supports caf files now. It has support for uncompressed built in and for compressed via the Export -> external command option where you can just feed it the afconvert parameters.

Cool, well if its the case I'll go for CAF files, send me that example ASAP, and write it using ANSI C ISO 99 and make it 100% platform independent, so I can integrate full support in the next revision.

Cheers!

Finally complete with compressed and uncompressed caf files with no AudioToolbox.framework requirement.

I can't say that my C experience is anywhere near enough to be sure that the code is ANSI C ISO 99 and 100% platform independent...but I'll send the files on over. Let me know if there is anything in there that isn't up to par.

Edit: Files are sent

SIO2 asked me to do a few benchmarks with a larger audio file. The following times and files are from the benchmark tests:

OGG file ( file.ogg / 3.4meg )
---START (sound/file.ogg): 3767868
---END start (sound/file.ogg): 3832807
------- TOTAL LOAD TIME (sound/file.ogg): 64939

Compressed CAF file ( compressed.caf / 3.9meg )
--- START (sound/compressed.caf): 3764228
--- END start (sound/compressed.caf): 3765824
--- TOTAL LOAD TIME (sound/compressed.caf): 1596

Uncompressed CAF file ( uncompressed.caf / 5.4meg )
---START (sound/uncompressed.caf): 3838728
---END start (sound/uncompressed.caf): 3838844
------- TOTAL LOAD TIME (sound/uncompressed.caf): 116

Perhaps the most interesting finding of all is that both the compressed and uncompressed CAF could be loaded and played simultaneously while the ogg file crashed the iPhone completely. It restarted the iPhone every time I tried to load the ogg file.

Hey man, I've been doing some conversion tests...

I test with an .mp3 ( 2:51 minutes / 2.1Mb )

-> OGG: 3.1Mb
-> CAF (U): 28.8Mb
-> CAF (C): 7.7Mb

I use what you previously post to convert to CAF

Code:



Uncompressed:
CODE:
/usr/bin/afconvert -f caff -d LEI16 {INPUT} {OUTPUT}


Compressed:
CODE:
usr/bin/afconvert -f caff -d ima4 {INPUT} {OUTPUT}



I am really wondering how you convert that MP3 and have the OGG almost as the same size of a CAF... Cuz from what Im seeing here... is that CAF is way too big and not usable...

Lemme know what you did...

Cheers,

When I did the test I modified the conversion to get the two files to be about the same size. The standard uncompressed caf settings make HUGE files that are really high quality and not at all necessary on a mobile device. I have found that changing the sample rate to a much lower value still creates a very good sound.

Code:

Uncompressed:
CODE:
/usr/bin/afconvert -f caff -d LEI16@SAMPLE_RATE {INPUT} {OUTPUT}


Compressed:
CODE:
usr/bin/afconvert -f caff -d ima4@SAMPLE_RATE {INPUT} {OUTPUT}

Example:
usr/bin/afconvert -f caff -d ima4@8000 some.mp3 niceSmallFile.caf


Let me know if that does it for you.

I have actually found that ima4 caf files at 8000 hz are really good sounding and I use very high quality Shure headphones for my testing.

Hummmmm I've done some further test based on your information and test with regular apple headphone and Im telling you at 8000hz it sounds like crap...

The best that I could find balancing ratio & size was 22050hz (anything higher than that gives a WAY too big file) which gives similar size as an OGG at 48000hz...

And still it really doesn't sounds that good... still sound like you are hearing the music from a can of coke or something... I would basically go for a standard encoding of 22050hz... However from what I test CAF is not the key...

I also check the .OGG that you send me, and the problem comes from the memory usage not the SIO2 code, which goes above 64Mb and make the device reboot. I think the answer is simple, Ambient sound should be streamed and FX sound should be fully loaded. FX sounds can continue to have multiple sound ID while Ambient sound can only have 1 sound buffer and is double buffered in a separate thread...

I do not think that the answer lies into CAF as the memory will still be really high when the CAF (used for an Ambient sound) is loaded...

So in summary:

Ambient sounds are streamed and cannot be shared by multiple sound source, Ambient sounds have a separate thread using double buffer and streamed from the sound buffer.

FX sounds stays the same as they are can still be shared by multiple sound source and are fully loaded and decompressed from client memory only once then reused as much as they have to...

Cheers,

Sounds good to me. I'll continue to play around with the different encodings and see what is optimal. With ambient being streamed that makes it a bit easier to use a file that is slower to decode for sure.