Howdy guys. Sorry for the crosspost. Patch to speed up taglib.

[Lukáš Lalinský]

On 10/12/07, Scott Wheeler <wheeler at kde.org> wrote:
> Manuel Amador (Rudd-O) wrote:
> > The right way to ward off these issues is to build a sizable corpus of
> > multimedia files and a decent test suite that stress-tests the code before
> > release.
>
> I've naturally had that for years.  "Broken", however, is not a
> well-defined state.  The easy cases are the ones where the files aren't
> playable at all.  But what about if they work, but the last quarter of a
> second is chopped off?

Well, but this is precisely the point of unit testing for specific
parts of your code. You define well-known good states in the unit
tests, and if the code ends up in an undefined state, you assume it's
broken. The problem is have a good test coverage of the file format
specifications. IME, having a sizeable curpus of files and doing
playable/unplayable tests is nice in early stages of writing code for
a new format and experimenting, but not if you try to ensure that the
code follows some specification.

As an example, ByteVector::rfind is currently broken and
tests/toolkit-test.cpp tells you so, but it have been like that for
quite some time. Fortunatelly, no code uses that specific code path,
but if somebody (like me) tries to use it in a new file format and the
code doesn't work in some cases, having a specific test suite is more
useful to identify the problem than doing some high-level tests over a
music collection.

Lukas