Skip to main content

Notice

Please note that most of the software linked on this forum is likely to be safe to use. If you are unsure, feel free to ask in the relevant topics, or send a private message to an administrator or moderator. To help curb the problems of false positives, or in the event that you do find actual malware, you can contribute through the article linked here.
Topic: oggcodecs 0.70.0827 released! (Read 15174 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

oggcodecs 0.70.0827 released!

Have at it... http://www.illiminable.com/ogg/

Well, finally got around to another release! I was extremely busy last year, and had very little spare time to work on this. I've been doing a few things over the last couple of months, and now is as good a time as any to release, or I will keep putting it off!

This is the start of the 0.7x line of development, I completely rewrote the demuxer, it's much easier to maintain now, and I fixed a few issues with timing.

The main things people care about in this new release.

* Seeks properly in theora... to any frame, without artefacts... (most of the time! there is a small bug and occasionally it misses the keyframe, but it's a lot better than artefacts every time)
* Seeking accuracy improved in all codecs. Everything seeks within 1 audio sample (ie. sub second) rather than to page or even packet boundaries.
* Works much better on staticly streamed files over http. Still no seeking over http.
* Upgraded most of the libraries a couple of months ago, but to just get a release done, I didn't get stuff that happened since then (ie spx 1.1.12 or vorbis 1.1.2) since I just want to release and have a new baseline to work from.
* Some improvements to .ogm, but I didn't get a chance to finish everything before the release. It does not attach itself to the .ogm extension to avoid messing with your current .ogm solution. You'll need to rename the file to .ogg to make it play. When the support is more reliable, I will attach to the .ogm extension.
* Fixed the audio level problem in flac.
* Synch should be a lot tighter now.
* Random other bugfixes.

But... I did have to break something. Previously it had a nasty trick to allow it to stream chained icecast streams... it was always a bad way, but it kinda worked. But now I can't get away with that. I will be looking to implement that properly when I get a chance.

Hopefully I will have a bit more time this year, and the release cycle can be back to how it was before the 1 year gap.

My goal for this project from the beginning was to make the easiest to use, most complete implementation of ogg (both encoders and decoders) for Windows, but there is still plenty of work to be done yet. They are BSD like the core xiph code to encourage the uptake of ogg on windows, and as such can and are used in proprietary applications.

Thanks to everyone who has given me lots of feedback. Please continue to do so, and report bugs to ogg@illiminable.com Hopefully I might make it 1.0 this year (that was last year, and the year befores goal too!)

Enjoy!

oggcodecs 0.70.0827 released!

Reply #1
Welcome back!

Nice to see some progress. I already thought this projects was dead.

oggcodecs 0.70.0827 released!

Reply #2
Thanks!!! 

I´m going to wait for the 1.0 release like I wait for this...   
JorSol
aoTuVb5 -q4

 

oggcodecs 0.70.0827 released!

Reply #4
Quote
And another release. Version 0.71.0946

http://www.illiminable.com/ogg/
[a href="index.php?act=findpost&pid=366711"][{POST_SNAPBACK}][/a]

Cool. Thank you!

oggcodecs 0.70.0827 released!

Reply #5
Quote
* Some improvements to .ogm, but I didn't get a chance to finish everything before the release. It does not attach itself to the .ogm extension to avoid messing with your current .ogm solution. You'll need to rename the file to .ogg to make it play. When the support is more reliable, I will attach to the .ogm extension.[a href="index.php?act=findpost&pid=364767"][{POST_SNAPBACK}][/a]

First off, thanks for the new release 
... directshow doesn't care about the actual file extentions, so renaming ogm to ogg won't make any difference 

I'm not completely against a new and better ogm parser... but it better really be 'better' than oggds. I have come to like the oggds parcer (for ogm) very very much.  Its great features are all available in its taskbar icon (you should do the same (or at least have the option in the case of ogm), the audio switcher, subtitle switcher, chapter selector, and filter properties. Its one drawback was that subtit1400 wasn't built into it and vsfilter doesn't like it very much that subtitles are off by default (have to enable then stop and start the video to use that subtitle filter with it..mostly a vsfilter deficiency IMO).... That said, when you do decide to take over ogm parsing, give us the option of using your filters for ogm or not.. and the many good features of oggds should be copied into your filters (at least for ogm).

I will be testing the new filters and see if some problems have been resolved...
Vorbis-q0-lowpass99
lame3.93.1-q5-V9-k-nspsytune

oggcodecs 0.70.0827 released!

Reply #6
Nice, I can finally use Theora without the horrible artifacts... and the seeking is very good...

...keep the good work...
JorSol
aoTuVb5 -q4

oggcodecs 0.70.0827 released!

Reply #7
Quote
First off, thanks for the new release 
... directshow doesn't care about the actual file extentions, so renaming ogm to ogg won't make any difference


Well actually it does care about file extensions. It decides which source filter to use based on file extension.

eg.... look in the registry here...
;[HKEY_CLASSES_ROOT\Media Type\Extensions\.ogg]
;"Source Filter"="{31CA0186-1FF0-4181-AA38-3CA4040BD260}"

The way it is now, no .ogm extensions will be loaded in my filter so long as they have an .ogm extension.

oggcodecs 0.70.0827 released!

Reply #8
Quote
Quote
* Some improvements to .ogm, but I didn't get a chance to finish everything before the release. It does not attach itself to the .ogm extension to avoid messing with your current .ogm solution. You'll need to rename the file to .ogg to make it play. When the support is more reliable, I will attach to the .ogm extension.[a href="index.php?act=findpost&pid=364767"][{POST_SNAPBACK}][/a]

I'm not completely against a new and better ogm parser... but it better really be 'better' than oggds. I have come to like the oggds parcer (for ogm) very very much.  Its great features are all available in its taskbar icon (you should do the same (or at least have the option in the case of ogm), the audio switcher, subtitle switcher, chapter selector, and filter properties. Its one drawback was that subtit1400 wasn't built into it and vsfilter doesn't like it very much that subtitles are off by default (have to enable then stop and start the video to use that subtitle filter with it..mostly a vsfilter deficiency IMO).... That said, when you do decide to take over ogm parsing, give us the option of using your filters for ogm or not.. and the many good features of oggds should be copied into your filters (at least for ogm).

I will be testing the new filters and see if some problems have been resolved...
[a href="index.php?act=findpost&pid=366735"][{POST_SNAPBACK}][/a]


Sure, I will try to make it optional... there some work that needs to be done to make the installer a bit better, so that's something that will be done then.

With regards to ogm, it's not that I particularly care about ogm, or want a new and better filter, but, that seems to be something that causes problems and conflicts for some people. eg. they want to play ogm, so they use other filters, and sometimes they find installing other ogm filters, means they can't use my filters for other ogg files.

I must say i get a lot of mixed signals about ogm, i get lots of people saying, don't worry, nobody uses it, and then i get lots of emails asking why they can't play their ogms. So i'd like a solution that works for most people by default, and if people can configure things differently for themselves, that's great.

oggcodecs 0.70.0827 released!

Reply #9
Quote
With regards to ogm, it's not that I particularly care about ogm, or want a new and better filter, but, that seems to be something that causes problems and conflicts for some people. eg. they want to play ogm, so they use other filters, and sometimes they find installing other ogm filters, means they can't use my filters for other ogg files.
[a href="index.php?act=findpost&pid=366811"][{POST_SNAPBACK}][/a]

the solution to that for me was to install oggds then install illiminable afterwards, oggds handles ogm and illiminable handles ogg... but when i reregistered the oggds parcer so I could use oggmux (which actually makes ogm  ) I had to completely reinstall illiminable afterwards to get them to parce ogg files again.....

(by the way, im downloading the new filters finally, ^^ that is one of the problems i hope is resolved... i made things easy for myself, i can right click on dshow filters and register or unregister them with regsvr32  )

and extention does not matter.. i still stand by what I said earlier.... just change a wma file to ogg.... it will still open and play with the wma filters.... change it to *.poopsmellsbad and it will still play.. i have yet to see one example proving to me otherwise
Vorbis-q0-lowpass99
lame3.93.1-q5-V9-k-nspsytune

oggcodecs 0.70.0827 released!

Reply #10
I tried this with a matroska file with Vorbis audio, and it didn't work. Installed CoreVorbis and everything worked fine.


oggcodecs 0.70.0827 released!

Reply #12
@gameplaya: try Haali Media Splitter for your ogm files...

oggcodecs 0.70.0827 released!

Reply #13
Quote
I tried this with a matroska file with Vorbis audio, and it didn't work. Installed CoreVorbis and everything worked fine.
[a href="index.php?act=findpost&pid=367343"][{POST_SNAPBACK}][/a]


These filters are for ogg not matroska. The decoders currently do a handshake with the ogg demuxer to give it the information it needs to do ogg parsing. This allows new codecs to be added without having to keep changing the demuxer, and having uneccessary codec information in the demuxer, since ogg does not have any standard way to get basic codec information.

Since they have a different protocol for connecting, they use different GUID's to matroska, and hence currently will not work together. If the matroska demuxer queries the correct interfaces and follows the convention all these filters use it can use them just fine if it chooses.

If the matroska demuxer only speaks the "language" that corevorbis talks, then it needs corevorbis.

oggcodecs 0.70.0827 released!

Reply #14
Quote
Quote
With regards to ogm, it's not that I particularly care about ogm, or want a new and better filter, but, that seems to be something that causes problems and conflicts for some people. eg. they want to play ogm, so they use other filters, and sometimes they find installing other ogm filters, means they can't use my filters for other ogg files.
[a href="index.php?act=findpost&pid=366811"][{POST_SNAPBACK}][/a]

the solution to that for me was to install oggds then install illiminable afterwards, oggds handles ogm and illiminable handles ogg... but when i reregistered the oggds parcer so I could use oggmux (which actually makes ogm  ) I had to completely reinstall illiminable afterwards to get them to parce ogg files again.....

(by the way, im downloading the new filters finally, ^^ that is one of the problems i hope is resolved... i made things easy for myself, i can right click on dshow filters and register or unregister them with regsvr32  )

and extention does not matter.. i still stand by what I said earlier.... just change a wma file to ogg.... it will still open and play with the wma filters.... change it to *.poopsmellsbad and it will still play.. i have yet to see one example proving to me otherwise
[a href="index.php?act=findpost&pid=367330"][{POST_SNAPBACK}][/a]


Yes, if you install oggds, it will overwrite the registry where illiminable filters are, then when you install illiminable again, it overwrites all of oggds except the part about .ogm

Also, illiminable does part of the registration in the installer, since certain entries are not specific to a particular filter, so it doesn't make sense to do that in the DllregisterServer which is all regsvr32 calls.

You can read the directshow docs about file extensions if you like. Some filters do byte sequence matching. Because ogg and ogm will both match a test for OggS string that is not a reliable way to differentiate.

I am telling you, my filter associates on file extension. What other filters do is not relevant. Get an *ogg theora* file, rename it to .xxx and try and play it.

oggcodecs 0.70.0827 released!

Reply #15
well another great solution for play Ogg Vorbis, Ogg Theora, OGM, Matroska, MP4 without any problems... is to install Haali Media Spliter and ffdshow... thats all you need for playback...

BUT... I test Ogg Theora using Haali and ffdshow (ff_theora and ff_tremor) and the seeking is SLOW compared to illiminable codec. 

I have to said that the Haali splitter is quite advanced... but if you are looking a complete ogg solution I recommend illiminable oggcodecs. 

Zen I like this filters a lot and I hope that in the future (maybe 1.0 release) this filters get highly stable, powerful. 

I dont have problems at all with OGM, this is what I do: install Haali without (yes without), the OGM support and using ffdshow (ff_tremor or libavcodec for vorbis, corevorbis works to)... and then install illiminable oggcodecs... if the file is OGM Haali is forced to play it (even if is disable in the installer)... and it don't mess up with the illiminable codecs. so I can play OGM and all my ogg's fine....
JorSol
aoTuVb5 -q4

oggcodecs 0.70.0827 released!

Reply #16
Quote
@gameplaya: try Haali Media Splitter for your ogm files...
[a href="index.php?act=findpost&pid=367382"][{POST_SNAPBACK}][/a]

I use haali for mp4... nothing else, I'm not fond of it

Quote
Yes, if you install oggds, it will overwrite the registry where illiminable filters are, then when you install illiminable again, it overwrites all of oggds except the part about .ogm

Also, illiminable does part of the registration in the installer, since certain entries are not specific to a particular filter, so it doesn't make sense to do that in the DllregisterServer which is all regsvr32 calls.

You can read the directshow docs about file extensions if you like. Some filters do byte sequence matching. Because ogg and ogm will both match a test for OggS string that is not a reliable way to differentiate.

I am telling you, my filter associates on file extension. What other filters do is not relevant. Get an *ogg theora* file, rename it to .xxx and try and play it.
[a href="index.php?act=findpost&pid=367525"][{POST_SNAPBACK}][/a]
ok you are right.... and I'm not sure if using the extention is really such a good thing.. seems your filters do fine with my ogv files though (ogg is associated to winamp so i have to use something else).. and the whole 'handshaking' thing I don't like

and on to a bug report:
same error as previous version, occurs at the end of a theora file (or ogg file with theora in it if you prefer)
Catastrophic failure  (Error=8000FFFF)
also, stopping, then playing again induses artifacts because the first keyframe isn't read
happens in mplayer2 and in graphedit (file was encoded with these filters too)
Vorbis-q0-lowpass99
lame3.93.1-q5-V9-k-nspsytune

oggcodecs 0.70.0827 released!

Reply #17
Quote
Quote
@gameplaya: try Haali Media Splitter for your ogm files...
[a href="index.php?act=findpost&pid=367382"][{POST_SNAPBACK}][/a]

I use haali for mp4... nothing else, I'm not fond of it

Quote
Yes, if you install oggds, it will overwrite the registry where illiminable filters are, then when you install illiminable again, it overwrites all of oggds except the part about .ogm

Also, illiminable does part of the registration in the installer, since certain entries are not specific to a particular filter, so it doesn't make sense to do that in the DllregisterServer which is all regsvr32 calls.

You can read the directshow docs about file extensions if you like. Some filters do byte sequence matching. Because ogg and ogm will both match a test for OggS string that is not a reliable way to differentiate.

I am telling you, my filter associates on file extension. What other filters do is not relevant. Get an *ogg theora* file, rename it to .xxx and try and play it.
[a href="index.php?act=findpost&pid=367525"][{POST_SNAPBACK}][/a]
ok you are right.... and I'm not sure if using the extention is really such a good thing.. seems your filters do fine with my ogv files though (ogg is associated to winamp so i have to use something else).. and the whole 'handshaking' thing I don't like

and on to a bug report:
same error as previous version, occurs at the end of a theora file (or ogg file with theora in it if you prefer)
Catastrophic failure  (Error=8000FFFF)
also, stopping, then playing again induses artifacts because the first keyframe isn't read
happens in mplayer2 and in graphedit (file was encoded with these filters too)
[a href="index.php?act=findpost&pid=368102"][{POST_SNAPBACK}][/a]


Thanks for the bug report. I'll take a look at that when i get home next week.

WMP will still open a .ogg file with my filters even if it is associated to winamp. It is two seperate sets of extension mapping, one maps for the shell from an extension to a program... ie. XXX is run when you double click extension YYY in explorer.

The other is a mapping from an extension to a directshow source filter. That happens internally. You can still do Open with->Windows media player, or Open file from within it on .ogg files even if winamp is the default application for .ogg files. If this is not the case, some other directshow filter has overwritten the entry, very likely due to you using regsvr32 to register and uregister, since as i said some of the regsitration process is in the installer.

So what would have happened is...
- You installed my installer, and it was all complete.
- You regsvr32 /u 'd my filter, but many of the core entries are managed by the installer, so this didn't do much
- You registered some other filter, which overwrote my entries
- You reregistered my filter, but since some of the entries are now overwritten and you didn't use the installer, the .ogg extension probably points somewhere bogus, but since your other ogg filter didn't overwrite the .ogv, .oga extension entries they were unaffected.

Using the extension is the best solution at the moment, but it will be changed to also use byte matching in the future when the ogm code is working reliably.

With regards to the handshake, it's not the way I wanted to do it, but after seeing the problems i ended up with doing it another way (ie in 0.69 and previous), i decided it was the best solution.

The handshake is transparent to users. The main motivation for this approach, is that ogg does not have any fixed headers unlike most other file formats, there is no consistent way to find essential information about audio sample rates, frame rates, timing information etc. The result was, the demuxer had to duplicate most of the codecs header parsing code. This is very messy since there are now 11 possible types of data it handles in ogg streams, CMML, FLAC(2 versions), theora, vorbis, speex, raw pcm, ogm video streams, ogm audio streams, ogm text streams, annodex fishead streams, each with their own quirks.

It also means that any new codec means rebuilding and redistributing a new copy of the demux. The idea is that seeing as ogg is a generic container format, a third party should be able to put a new codec inside it, distribute their decoder and have it just work. By allowing the demux to handshake with the decoder on setup, it can get the decoder to provide it with specific information about that codec. Ogg has dependancies between demux and codecs that don't exist in most other media types, a tightly integrated solution allows me to do make a more fully featured, more stable solution.

In the future, when the code and interfaces are close to being final, i will look at making the decoders in my package accept data without the handshake, but for now, it greatly simplifies development. Since some interfaces are still changing as releases go on, it means i don't end up breaking other filters and applications if i change things, which means i can develop faster. It also means that they can happily co-exist with other decoders for vorbis and theora etc, since they will never try to connect to other filters which might result in unpredictable behaviour for the user. For example if it worked in a way identical to ffdshow or corevorbis, those filters could potentially be used instead by directshow but they do not have the required functionality to do what the demux requires.

Primarily my interest is making a reliable working solution for ogg, my interest in other formats at this stage really only extends so far as not breaking any users playback of them.

oggcodecs 0.70.0827 released!

Reply #18
Quote
- You regsvr32 /u 'd my filter, but many of the core entries are managed by the installer, so this didn't do much

Actually, I used regsvr32 on the oggds filter, which overwrote the entries for ogg... It is merely a matter of convienience that I wish your filter would overwrite its entries back when regsvr32 is used on it (the demux filter specifically).. it would just save me the trip of using the installer again and (re)moving the start menu entries  (yes I'm complaining about the 30sec it takes to do this  )

also... your filter isn't listed in my decoders list (in mplayer2).. the old version at least had the file path and a little explanation of what illiminable was, its not there in this one  why? (personally I'd like to see all the filters show up, and the vorbis decoder to tell me useful stuff like the bitrate)

and... still no vorbis encoder config? (no filter properties in graphedit  )

ps: i use 'open with' on a daily basis, ya dont have to explain that kind of stuff
Vorbis-q0-lowpass99
lame3.93.1-q5-V9-k-nspsytune

oggcodecs 0.70.0827 released!

Reply #19
illiminable,

Thanks for your efforts!  It's nice to have multiple ways to enjoy oggs.

I read the release notes, known issues, etc., but I didn't find anything about ogg metadata tags.  Using WMP, my tagged oggs do not show any of their tags using the oggcodecs.

Sorry if this is covered elsewhere,

John

oggcodecs 0.70.0827 released!

Reply #20
Quote
illiminable,

Thanks for your efforts!  It's nice to have multiple ways to enjoy oggs.

I read the release notes, known issues, etc., but I didn't find anything about ogg metadata tags.  Using WMP, my tagged oggs do not show any of their tags using the oggcodecs.

Sorry if this is covered elsewhere,

John
[{POST_SNAPBACK}][/a]


Hi, yes this is still an issue. For a long time i didn't know how to make it integrate with WMP, or if it was possible. Though someone else has written something to do this that should work with oggcodecs (i haven't had time to try it yet, but i'm told it works)

[a href="http://wmptagext.sourceforge.net/]http://wmptagext.sourceforge.net/[/url]

This adds tagging support for several types of files, though some including vorbis are read only. I woul dlike to integrate something like this just for ogg in the futureinto oggcodecs, but have not had time. Including write support and for all the other xiph codecs. I've been meaning to have a closer look at this project for a while.

Let me know if this works for you.

oggcodecs 0.70.0827 released!

Reply #21
I've been playing with the theora encoder... it's quite nice I must say  .... but I'm at a loss on the config.. http://www.illiminable.com/ogg/images/theora_properties.JPG ... my file ended up much larger than I wanted...

my question is about the 'quality' slider. Is it encoder quality, or quantizer (like in vp3). If so, then how does the bitrate play in?... let me rephrase...
1. How would I encode based on bitrate?
2. How would I encode based on quantizer?


and some more...
I tried muxing 2 seperately encoded ogg files (one theora, one vorbis), but It would'nt let me directly copy the stream. Is this a bug? or maybe just an oversite with the handshaking the filters are doing?


and then...
Large files (~700mb) take a long time to open. It looks to me from my hard disk activity that the filters are scanning the whole file before it plays, happens in all directshow applications (plays right away in vlc).  I didn't see this listed in the known issues.
Vorbis-q0-lowpass99
lame3.93.1-q5-V9-k-nspsytune

oggcodecs 0.70.0827 released!

Reply #22
Quote
illiminable,

I read the release notes, known issues, etc., but I didn't find anything about ogg metadata tags.  Using WMP, my tagged oggs do not show any of their tags using the oggcodecs.
[{POST_SNAPBACK}][/a]


WMP does not use the DirectShow filter for tag information. It uses another kind of plugin. He is a free one that handles most all tag formats.
[a href="http://www.softpointer.com/WMPTagSupport.htm]Tag plugin[/url]

oggcodecs 0.70.0827 released!

Reply #23
Quote
I've been playing with the theora encoder... it's quite nice I must say  .... but I'm at a loss on the config.. http://www.illiminable.com/ogg/images/theora_properties.JPG ... my file ended up much larger than I wanted...

my question is about the 'quality' slider. Is it encoder quality, or quantizer (like in vp3). If so, then how does the bitrate play in?... let me rephrase...
1. How would I encode based on bitrate?
2. How would I encode based on quantizer?
Yes, that is still complicated to use (or understand), I only use the quality slider, and yes is quality not quantizer, since for high quality you have to choose big values eg. 60 (in quantizer you have to choose lower values for high quality eg. 2). Im not sure if you understand me...    and is dificult to predict the final size using the quality. For both questions I have no idea how.

Quote
and some more...
I tried muxing 2 seperately encoded ogg files (one theora, one vorbis), but It would'nt let me directly copy the stream. Is this a bug? or maybe just an oversite with the handshaking the filters are doing?
yes, thats a bug, I send an email to illiminable and confirmed that... he said that is because the change in the interface on the output of the demuxer (remember that he rewrote the demuxer in the v0.70), but he can tell that better than I. (correct me if I'm wrong illiminable).

Quote
and then...
Large files (~700mb) take a long time to open. It looks to me from my hard disk activity that the filters are scanning the whole file before it plays, happens in all directshow applications (plays right away in vlc).  I didn't see this listed in the known issues.
[{POST_SNAPBACK}][/a]
Is not listed in the know inssues but when the v0.70 was released in the changes said: # "Be aware that it builds a seektable for all on-disk files. For really large files (>250MB) it may take a little while for the file to load" (See the [a href="http://www.illiminable.com/ogg/history.html]history[/url] page).
JorSol
aoTuVb5 -q4

oggcodecs 0.70.0827 released!

Reply #24
Quote
Quote
I've been playing with the theora encoder... it's quite nice I must say  .... but I'm at a loss on the config.. http://www.illiminable.com/ogg/images/theora_properties.JPG ... my file ended up much larger than I wanted...

my question is about the 'quality' slider. Is it encoder quality, or quantizer (like in vp3). If so, then how does the bitrate play in?... let me rephrase...
1. How would I encode based on bitrate?
2. How would I encode based on quantizer?
Yes, that is still complicated to use (or understand), I only use the quality slider, and yes is quality not quantizer, since for high quality you have to choose big values eg. 60 (in quantizer you have to choose lower values for high quality eg. 2). Im not sure if you understand me...    and is dificult to predict the final size using the quality. For both questions I have no idea how.

I screwed up when i did those encoding parameters. I really didn't even understand myself how they worked, they were just some variables in libtheora and i just chucked some sliders on them  But since then i've done a lot more playing around with things, and i now know that quality setting always overrides bitrate setting... there's also a couple of other settings that i want to expose. As to the quantiser settings, i'd really have to spend a bit of time talking with one of the theora devs to find out more information about how i should expose that. But for now, you pretty much can't do that with the filters.

If you want to use bitrate setting in the current version, make sure you set quality to 0. If quality is any other value, it seems to ignore bitrate, which kind of makes sense. I had thought initially that quality also had some other impact in terms of encode complexity etc, but setting both parameters is not actually meaningful. I only figured this out myself a few weeks ago.

It probably won't be into the next release, that should be fairly soon, but it and hopefully vorbis, and possibly speex encode settings should make it into the release after that. The underlying code is already there for vorbis, not yet for speex, since it has some more complex interactions between settings that i have to figure out.

What jorsol said about the other issues is correct. Re: the load time, since it relies on seektable to give very good seek performance, the load time does kind of suck for large files. When i implement the slower binary search seeking method, which is needed for seeking over http, i will be able to make it optional for on-disk files. ie you choose a one off load time penalty or an every time seek time penalty.

Ideally the user should be able to set a threshold file size, say 100-200MB or whereever the load time becomes "too long" for their machine. On small files, like most audio files, the seektable builds so quick you don't notice it.

Incidentally, it has always built a seektable even from the first ever version. It's just more recently people are using larger files, so i though i should mention it again.

There is certainly some significant optimisation that could happen in the seek table building, but it's always going to be limited by the speed it can read off the disk, and this is made worse if the disk is a CD/DVD. Also, i have never tried it on >4Gig files, but i'm 99% sure, that there are some 32bit limitations in the current code that need to be fixed. But then again a 4 Gig file would currently take a really really long time to load, so it's probably not going to affect anyone just yet