From: Brian Rodgers <bkrodgers_at_bigfoot.com>
Date: Tue, 8 Apr 2003 16:24:46 -0500

-----Original Message-----
Yes. Technically, there are two things that kill track skipping speed:

1) Bit swapping. Due to annoying circumstances, the MAS and the CPU does not
have the bits of their bytes in the same order! Thus every single byte we
read from disk has to be bitswapped before we feed it to the MAS.

2) ID3 tags. We can't display the song info before we have it. And that info
is sometimes stored *last* in the file (id3v1). Thus we need to seek to the
end of the file, then read and parse the tag, before we can display it.

I and Linus have discussed various methods of speeding things up, but
nothing that makes a huge difference. I think a playlist browser is a
priority.

---
OK, understandable.  What if, after loading up a playlist, it read the ID3
tags into memory in the background?  Is this possible?  If it can be done
without much overhead, that would enable a faster update of the display.
OR, how about this -- if you're trying to browse through the playlist
quickly with ff/rew, it could just display the filename and playlist order
number (it should already have that loaded, right?)  Then once you stop on a
track and it loads the actual file, it can update the WPS with the ID3 info.
The visual feedback of being able to go quickly through the playlist like
this would be very nice, even once the playlist browser is in place.
-Brian

Received on 2003-04-08