I used to get a lot of albums from places like CDBaby and eMusic. The eMusic files in particular were low resolution, and I sometimes find them difficult to listen to. Similarly, early CDBaby files were in a less-than-desirable VBR form, before they switched to standard 320kbs or flac. Sadly, they no longer offer their files in flac, but everything I ordered back in the day is still available in 320. So I decided to re-download a set of those older files to get the better grade of compression.
But an odd thing has happened with some of these, and I can't figure it out.
My work process was to download the file, unpack them to a convenient location and copy to my primary archive having deleted the old files (including the folder for the recording), and then re-creating with the new files. I then did the necessary massaging with MP3Tag.
Next step was to copy to my networked music folder, which lives on a hard drive attached to my dedicated music server running Win7. Windows Explorer wouldn't let me delete the entire "old" folder, because it wouldn't delete the Thumbs.db file, declaring it to be open in Windows Explorer. It wasn't, on the computer I was using, but it may be that LMS's presence on the remote computer was causing Windows to think this. I didn't think it made a difference, so having deleted all the old mp3 files, I then copied the new higher-res ones into the folder. I waited for the automatic nightly scan for new/changed content, assuming it would pick up the new files since the names were different and there would be a new date-stamp.
In most cases, this worked fine. In a few, though, the LMS scan resulted in two listings for an album, each holding a subset of the files. In all cases, the files were in fact new files, in both listings, so the new/changed seek worked.
I have checked, and can see nothing different in the parameters that should count, e.g. album name, artist, album artist, or anything. All were processed simultaneously with MP3Tag and all should have exactly the same configuration. As noted, this is happening only with a subset of the recordings, all of which were handled in exactly the same way.
I haven't forced a complete re-scan, which would be a nuisance.
Suggestions?
R.
But an odd thing has happened with some of these, and I can't figure it out.
My work process was to download the file, unpack them to a convenient location and copy to my primary archive having deleted the old files (including the folder for the recording), and then re-creating with the new files. I then did the necessary massaging with MP3Tag.
Next step was to copy to my networked music folder, which lives on a hard drive attached to my dedicated music server running Win7. Windows Explorer wouldn't let me delete the entire "old" folder, because it wouldn't delete the Thumbs.db file, declaring it to be open in Windows Explorer. It wasn't, on the computer I was using, but it may be that LMS's presence on the remote computer was causing Windows to think this. I didn't think it made a difference, so having deleted all the old mp3 files, I then copied the new higher-res ones into the folder. I waited for the automatic nightly scan for new/changed content, assuming it would pick up the new files since the names were different and there would be a new date-stamp.
In most cases, this worked fine. In a few, though, the LMS scan resulted in two listings for an album, each holding a subset of the files. In all cases, the files were in fact new files, in both listings, so the new/changed seek worked.
I have checked, and can see nothing different in the parameters that should count, e.g. album name, artist, album artist, or anything. All were processed simultaneously with MP3Tag and all should have exactly the same configuration. As noted, this is happening only with a subset of the recordings, all of which were handled in exactly the same way.
I haven't forced a complete re-scan, which would be a nuisance.
Suggestions?
R.