Magnus Brading
Almighty Author

Group: Super Administrators
Posts: 2751
Joined: Aug. 2002 |
 |
Posted: May 16 2003,00:13 |
 |
Thanks for the info and the tests Tony!
I don't have any explanation for why your test runs show such varying times (out-of-application factors are highly suspected for such a thing though, like operating system memory management and such), or for the complete lock-ups you said to experience with some files, but I have explanations for some of the things you mention though:
Tagging some files take 1-10 seconds, while others are instant: When writing an ID3v2 tag to a file that does not already contain an ID3v2 tag (with enough padding), the entire contents of the file have to be rewritten (Disposable Hero mentions this above too). Depending on the size of the file, the speed of your storage device and the cache conditions of the storage device, this might take 1-10 seconds (and even more for really big files). Writing only ID3v1 tags, or writing ID3v2 tags to files that do already contain an ID3v2 tag (with enough padding) should always be practically instant though (with exceptions for situations related to my next explanation).
A bunch of files are tagged quickly, then it pauses on one file, then a bunch of files are tagged quickly again, then pauses, and so on: This is due to the behavior of the so called "write caches" in modern storage devices. When you write data to a modern harddisk, it often stores the data in a fast internal cache memory chip. It then writes the data to the actual magnetic disk a moment later, when it is not busy serving requests from the user. This cache memory is only of limited size though, and several consecutive writes (of the type that e.g. a mass tagging operation in Mp3/Tag Studio produces) will fill up the memory completely. When this happens, data must be written to the magnetic disk of the harddrive before anything else can be done, and it also often takes the opportunity to dump all the data currently in the entire cache to the disk at this point. This can be several megabytes (often 4-20) of data, destined for scattered locations all over the disk, and writing it can hence take several seconds. Thus, it seems like the pause is only occurring for a certain single file, but it is actually the data of all the previous files (since the last "pause") that is written too. All this is done at a level way beyond the control of normal applications, sometimes even beoynd the control of the operating system. It is also very hard to reproduce the exact locations of these pauses when the same operation is repeated, since it is practically impossible to restore cache-conditions similar to any other time it was performed.
I hope this at least cleared some things up.
Also, I have used Mp3/Tag Studio quite much myself, on a pretty big collection, for a pretty long time (I promise, it's a registered copy ), and I have only experienced such a thing on one single instance out of all these numerous sessions. Hence, these problems might not all be entirely located in the program itself, but partially also on a lower level, out of my control (i.e. related to the local system of the user, like operating system, hardware and other factors). This hypothesis would also be supported by the fact that all such reported problems are very hard to reproduce, even on the same computer, and there is nothing in the code of Mp3/Tag Studio that will treat a certain file anything less than identical on any consecutive repetitions of the same operation.
But as always, if anyone has a sample file and/or operation that is able to reproduce any problem, you are very welcome to send them to me, and I will take a look!
-------------- Software author and website owner
|