On Thu, Nov 04, 2010 at 05:56:29PM +0100, Bertrik Sikken wrote:
> > Hi,
> > Are there fundamental reasons not to commit FS#8806? I know that ideally
> > we want all sound formats to play via a codec and not a plugin, but the
> > way I understand these tracker formats, the codec buffer size would
> > really limit the usefulness of such a thing.
> > This patch has been on flyspray for ages. It would be nice to finally
> > be able to accept it.
> Another question, just to get this clear:
> Are you pushing for inclusion of the mikmod *plugin* or the mikmod *codec*?
Personally I have no firm opinion, but I believe a codec makes more
> The last patch on that FS task (1 october 2010) is a codec patch.
> What are the pros and cons of a plugin vs. codec in your opinion?
The way I understand it, our buffering and codec system assumes that
while a codec may have to keep some state, it will never need random
access in the file. MOD files don't fit that model well. They basically
contain samples and sequences of notes to play, which basically implies
I believe (although I haven't looked very deeply into this) that this
means that doing this as a codec will mean imposing a limit on the size
of MOD files we can play. Moreover, ideally we want to reduce the codec
buffer, which would limit the supported size even more.
> At least for .mod files, I know they have at least the following limitations:
> * very limited metadata (basically just the title of the song)
> * many (all?) .mod files are looping, so there isn't a good definition of
> track length, also a looping .mod has no end after we can skip to the
> next .mod
> * we can't seek in a .mod (at least our mod player can't)
> IMO, considering these limitations (but I only considered only .mod files)
> I think having it as a plugin instead of a codec is no problem.
> Kind regards,
"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it." - Brian W. Kernighan
Received on 2010-11-04