-Brading Software Message Board
+--Forum: Mp3/Tag Studio Support and Bug Reports
+---Topic: Slow tag reading on some files started by chrispitude
Posted by: chrispitude on Nov. 26 2006,15:19
Hi all,
I am seeing a behavior that I can't explain. I am doing a "custom file list" compilation of my MP3 collection. What I am seeing is that for some CDs, the files take a few seconds each to have their tags read, while others complete in a fraction of a second. The "good" CDs are processed in about a second, and the "bad" CDs take a good 20-30 seconds each.
I can reproduce this when I manually browse tags. For the bad CDs, it takes multiple seconds to refresh the tag entries when I select different files in the directories. For the good CDs, the tags refresh in just about realtime.
What would cause this, and how can I fix the slow files so they read quickly?
Thanks!
- Chris
Posted by: Magnus Brading on Nov. 27 2006,13:36
Is it always the same files that read slowly? Otherwise I would guess that the delays are due to re-reads of the CD. Many CD-players can spin down/up when they have to re-read certain portions of CDs, and especially CDRs, which would cause such time delays.
Does the same thing happen when the files are on the harddisk, and in that case is it always the same files?
Posted by: chrispitude on Nov. 27 2006,15:55
Hi Magnus,
Thanks for responding! I probably wasn't clear in my post. When I refer to CDs, I am actually referring to a directory of MP3s on my drive. It happens very repeatably - a file is either fast or slow. It also seems to happen by album directory - some are fast, and some are slow. I'm guessing it's a consequence of how the files were ripped. I've used a variety of rippers and encoders over the years.
I can provide two example files if you like. My attempt to create a list of my collection has been running for three days now, and it would be nice to get to the bottom of this.
- Chris
Posted by: chrispitude on Nov. 27 2006,16:13
Hi again,
It occurred to me that I did not mention that the collection lives on a linux server, shared with Samba over the network. I access the files with a mapped network drive from the WinXP box.
I copied some good and bad test files over to the WinXP machine's local drive, and they all seem fast there. It's only when accessing them over the network on the linux box that it gets terribly slow.
What I don't understand is, why are some files still fast over the network? Is it possible for MP3 tags to live at the beginning or the end of the file, and maybe some files require a seek or scan that Windows Samba doesn't support as fully as a local filesystem?
- Chris
Posted by: Magnus Brading on Nov. 27 2006,16:56
If the files have some crap in the beginning, before the mp3 data after the ID3v2 tag, some seeking may occur. Otherwise it shouldn't. Anyway, glad to hear that the problem is apparently not in Mp3/Tag Studio.
Posted by: chrispitude on Nov. 27 2006,18:49
Hi Magnus,
I would appreciate any help you can give me in resolving this issue. This is basically a showstopper for me, as any attempt to perform a tagging operation to the database takes days. The WinXP machine I have is just a laptop which doesn't have enough storage to allow me to tag the files locally.
What can I do to look inside the structure of these files and look for culprits. Do you have the ability to set up a Windows fileshare to try some test files I could provide? Although it doesn't happen with MP3TS on a local drive, it does still seem to be some strange interaction between MP3TS with a networked drive.
- Chris
Posted by: Magnus Brading on Nov. 28 2006,10:49
When you say "tagging operation", do you mean writing tags to files? Because this will have a considerable differance between files that already have an ID3v2 tag and files that don't. The first time a file has data written to its ID3v2 tag (i.e. when the ID3v2 tag is created), the whole file is rewritten, which will make a noticable difference, and especially over network. You only mentioned a "read-only" operation at first though, i.e. creating custom lists?
In the case of writing tags faster, I could recommend taking a look at the "Super fast v2 tagging" setting in the "Tagging Core Settings" section of the global settings (read the help section for it first! ).
To be able to analyze the files for the defects I mention, you must be familiar with the internal binary format of both ID3v2 tags and mp3 frame headers.
Posted by: chrispitude on Nov. 29 2006,00:30
Hi Magnus,
This is where it gets strange.
When my collection was small and ripped only with AudioGrabber, it was normal that the first time I wrote tags with MP3TS, it always took longer as it shifts all the data to make room. Once the tag space was expanded, writes were fast. And, tag reads (browsing) were always fast.
I think my switch over to ExactAudioCopy and LAME 3.96.1 is the trigger for this slow behavior I'm seeing. For these "slow" files, both reading and writing is very slow - even when I mass-set the tags multiple times! Basically, the "slow" files are always slow for reading and writing no matter what.
I don't know anything about an MP3's structure, but I have a pretty good concept of file I/O. There is something strange about these files that are causing every read or write operation to need to chug through the file. I can't figure out why it happens only for files which aren't on the local drive. The good files write fast even when sitting remotely on the linux server (once their tags are expanded).
Unfortunately, since I have reripped almost everything in my collection with EAC/LAME, now I have crippled pretty much everything sitting on my server for any tagging purposes. I'm really confused.
- Chris
Posted by: Magnus Brading on Nov. 29 2006,00:39
Please try the Mp3/Tag Studio repair type that removes junk data before the first mp3 frame header on one of the troublesome files, and see if it makes any difference. Backup the file first.
end