> The next step will be harder. Because for what you have in
> mind, we would need a good low level/ripper library
> (= transforming audio data from a CD into a wav file) that
> must be available on many platforms, for many devices
> (IDE and SCSI) to set a standard.
The beauty of a system like this would be that it could also be
embedded in players, not just rippers. Players would have access
to existing ID3 tags too. Just think how much easier it would be
if you could update a handful of database entries whilst you
are playing instead of the once-only ripping phase?
> If you want to work on this, I can give you some hints,
> but I myself have to do some (more trivial) homework yet
> before tackling something like this.
I'd love to, but I don't have a clue about sound analysis or
FFTs. I'd definitely assist someone more knowledgable in the
field.
:> But processing the whole content of the audio CD before a match could be
:> made is a process that takes too long, even on 40 speed CD-ROMs.
: And not everyone has such a quick drive yet. So I think it is maybe a
: bit too early for that idea.
I, also, think that it would only make sense to process the first N
seconds of a track, not the whole thing.
:> ratio are helpfull in this. A simple quanitisation of the energy
:> distribution in the frequency spectrum would probably do the trick.
: Might work in some cases but not in all (like finding a 5s long sample
: in a 5min recording)
I don't think that would be a requirement.
Paul (who's desperately trying to figure out how to organise a few
Gigs of MP3s for his empeg player)