MP3 scanning reads whole files and hogs CPU while doing it

Submitted by Elfy on Sun, 02/19/2012 - 05:09
Description: 
I see that after sharing a folder slskQT starts reading all mp3s in it. I'm guessing it is done to extract tag and stream parameters (like bitrate and time). But right now slsk reads _whole_ files while consuming a lot of CPU power. It obviously makes this process slow. The thing is, the only case when reading whole file should be necessary is when we deal with broken streams, like vbr without Xing header, or output of various mp3 splitters. My request is therefore to drop this feature, or make it optional. I.e. not to read every mp3 from start to end.
0
Your rating: None
1
Average: 1 (1 vote)

Comments

Submitted by Nir on Sun, 02/19/2012 - 16:56.

The SoulseekQt MP3 scanner doesn't exactly read entire MP3 files, but rather seeks to MP3 frame boundaries to read format information. Whether or not that differs from reading the entire file in each case due to caching for example is an interesting question. I originally decided to write my own MP3 analysis function for SoulseekQt due to the many inaccuracies produced recently by the MP3 scanning library used by the original Soulseek client. Instead of trying to interpret header information, the new scanning function actually does statistical analysis on the totals of each frame in the MP3, which I believe has a lesser chance of producing inaccurate results. Then again, I'm far from an expert on the MP3 format, so I'm open to suggestions. That said, I don't find the process to be particularly laborsome on either my laptop or desktop, and at worst this is usually only done once for every shared MP3, so I'm not entirely convinced that this is a critical matter.

Submitted by Elfy on Tue, 02/21/2012 - 01:56.

Yes, as it is only done once it's not critical. That said, it's still takes more than an hour of 100% disk and CPU load for some shares :)

The way of full scanning is indeed most precise, it only concerns me because for any well-formed stream it is absolutely unnecessary. Incorrect results were most likely due to bug or lack of support for ID3v2 (like if a file is scanned for first sync code of mpeg frame and there is a picture embedded in ID3v2 it's easy to see how this process can fail).

So, not high priority, but I say there are better way to handle it.