grishnav
Unregistered
|
 |
Posted: April 01 2003,14:18 |
 |
| Quote (Magnus Brading @ April 01 2003,13:32) | I'm not completely sure about what you do when this happens. 
Could you please specify which tools and templates you are using inside Mp3/TS, and also give an example including full paths to the files that get renamed with #2s?
(sorry for answering this so late, it seems like I didn't see this post until now due to some error in the email notification of the board) |
I'm using the template I posted above:
c:\mp3<\><Artist><\><Album><\><TrackNr>-<Title>.mp3
Where c:\mp3 is the base of my collection, and MP3/TS is set to "advanced" mode to accomadate it.
Lets say I have c:\mp3\Darude\01 - Sandstorm.mp3
Lets say I rip Darude - Drums of New York from a CD (Darude - Drums of New York.mp3).
I drop Darude - Drums of New York.mp3 into c:\mp3, then go to MP3/TS, where my template is all ready to go, and hit "Execute"
When I go back into my Darude folder (which would actually be something like Darude\Before the Storm\*, but it's pretty much irrevelant), Darude\02 - Drums of New York.mp3 will be there correctly, but Darude\01 - Sandstorm.mp3 will now be Darude\01 - Sandstorm #2.mp3
If I go back to MP3/TS and hit "Execute" again, Darude\01 - Sandstorm #2.mp3 is renamed to Darude\01 - Sandstorm.mp3 again (as it was originally), but now Darude\02 - Drums of New York.mp3 is Darude\02 - Drums of New York #2.mp3
I'm assuming this occurs because when MP3/TS goes to write the new file, it sees that one already exists, when in reality it should simply skip the file as no renaming operation is needed.
A current workaround is to change something simple like the seperator, and then change it back. So, in the example above, for example, I would be using something like <TrackNr> - <Title>. I can temporarily change this to something like <TrackNr>-<Title>, and all of the files will be named correctly (No #2's), but will have a new seperator. I can then reset my previouse seperator (" - "), and all new files will be renamed. This seems to support my theory about what's happening.
My theory about the bug is drawn from another related observation I made with MP3/TS. If two differently named files contain identical ID3 tags, when MP3/TS goes to rename it, one will end up with the proper convention, and the other will have a #2 appended to it. The reason for this is obvious: it avoids accidently overwring one MP3 file with another if the tags are the same (perhaps they have different bitrates or something).
What MP3/TS *seems* to be doing is, opening an existing MP3, reading it, attempting to rename it, detecting that a file with the same name already exists, appending a #2 to avoid an accidental overwrite, and then deleting the original file.
In reality, MP3/TS should check to see weather the file it's currently working actually needs to be worked on. If MP3/TS checked to see weather the current filename (and path! would change if MP3/TS were to make the modifications according to the template, this problem wouldn't exist.
But again, this is just my semi-educated observation. I could be completely off the wall. Whatever it is, it don't work quite right.
|
