Hi Rob,
I remember you mentioning that you might implement a sort of mad-ogg which was a integer-only ogg vorbis decoder, but you were stymied by the lack of a proper specification for the ogg vorbis format.
Now that Tremor has been released, do you still plan on making such a project?
Thanks, Joe
On Wednesday, June 11, 2003, at 01:57 PM, Joe Drew wrote:
I remember you mentioning that you might implement a sort of mad-ogg which was a integer-only ogg vorbis decoder, but you were stymied by the lack of a proper specification for the ogg vorbis format.
Now that Tremor has been released, do you still plan on making such a project?
In part the release of Tremor has alleviated the need for a new implementation. While I do still think an alternative may be useful, I haven't yet decided whether I will write one.
What has people's experience been with Tremor? Is there anything lacking that a new implementation might be able to address and overcome?
On Wed, 2 Jul 2003, Rob Leslie wrote:
On Wednesday, June 11, 2003, at 01:57 PM, Joe Drew wrote:
I remember you mentioning that you might implement a sort of mad-ogg which was a integer-only ogg vorbis decoder, but you were stymied by the lack of a proper specification for the ogg vorbis format.
Now that Tremor has been released, do you still plan on making such a project?
In part the release of Tremor has alleviated the need for a new implementation. While I do still think an alternative may be useful, I haven't yet decided whether I will write one.
What has people's experience been with Tremor? Is there anything lacking that a new implementation might be able to address and overcome?
I don't think the current Tremor CVS is lacking in any way to justify a competing implementation.
The initial Tremor release was rather suboptimal in some ways, but all the changes I've produced to address them are now merged in the CVS. There is also a low-mem branch for reduced memory footprint to the cost of slightly higher CPU usage.
In short, unless someone has a brilliant idea to implement Ogg Vorbis decoding with totally different algorithms, it's probably more productive to improve on the current Tremor code IMHO.
Nicolas
On Wed, Jul 02, 2003 at 04:37:13PM -0700, Rob Leslie wrote:
What has people's experience been with Tremor? Is there anything lacking that a new implementation might be able to address and overcome?
Interface is basically the same as the regular ogg's interface. (There are ints passed instead of floats for some arguments; but that's rather obvious why).
If you like the ogg library interface (and I do), there are no complaints here concerning tremor. I have not had a chance to see how well it performs on my target platform (200mhz strongarm), but it used roughly the same CPU utilization as the regular ogg library on my development box (400mhz intel celeron).
And I'm going to add this next (long) bit not because I dislike libmad (it is very fast and works well), but because we mentioned ogg, mad, and improvements in the same email:
If I were to pick something to improve it would be the high-level library interface for libmad. The vorbisfile interface is very program(er) friendly. However the libmad one is a little harder to use. (Though, there is the advantage/complexity tradeoff of having 24bit samples in libmad).
To compare, my player's abstraction files for the two interfaces are 110 lines for vorbisfile and 208 lines for libmad. The biggest (I assume avoidable) complexity that libmad has is the hand-off of new raw data for construction of a frame.
That is for libmad, one has to feed a buffer that may not be entirely consumed, and one is responsible for re-sending the unconsumed part.
For vorbisfile, one just hands off a file-handle.
(Luckily, for my libmad routines, mmap makes things pretty fast and reasonable to code).
An interesting note, though, is that vorbisfile's documentation (to my memory) implies that the requested output frame size (you may specify) will be constant. It is, in fact not, but may be very small or very large. (I suppose due to modulo math and the difference between actual frame size and you specification).
On the other hand, libmad quite plainly states that you may receive any size for a frame (since it chooses to return a whole frame). It even warns that this size may change. (But in practice rarely does, though one can hardly ignore it when it happens!)
The point I'm making for this last bit was that vorbisfile would probably be better off using libmad's idea of returning the whole frame. But actually it would be nice if both went a step further than vorbisfile: The library should be told how much to fetch, and it returns that much unless EOF (or stream error, etc.). Just like a regular file read.
Overall, that's the interface that's ideal, give it a file handle (or at worse, a buffer pointer and size) and then read from it like it were a file. vorbis file is pretty close (and if you don't mind getting small "frames" it meets that mark), but libmad is pretty tough in comparison.
Again, I hope this is viewed only as constructive criticism. I, of course, thank all the hard work going into -all- the libraries that I use.
Thanks for list'in.
-Adam Luter
-
Adam Luter -
Joe Drew -
Nicolas Pitre -
Rob Leslie