So, I'm guessing it's a setting of dbPowerAmp that I set wrong, but because over time I used multiple versions/installations, it did not happen consistently. For the few albums I recently ripped just with MediaMonkey, the Disc 1/ID3v2 issue hasn't showed up. (I decided that that, using AccurateRip, would be good enough.) But the problem doesn't occur with everything I've ripped, or in any pattern I've spotted yet. At one point when I was first ripping my CD library, I tried using EAC, but I believe I gave that up early in favor of dbPowerAmp. So far, this problem has applied to whole albums. I'm re-scanning with Squeezebox Server now, to confirm that this fixes the problem, but some evidence suggests it does. So far, I'm just testing - one/few folders at a time, so I haven't used filtering (thanks for the hint), but have used sorting to pick out only the ID3v2 tags.
Also, editing with MediaMonkey goes very quickly.Īll the files have cover art embedded already not sure if that slows things up. Note that in using tag cut/paste, the cut portion is the slow one. However, it's really slow, so I'm guessing that the files are being re-written, as you suggest.
#Musicbrainz picard saved grayed out windows#
My files are indeed stored on a ReadyNAS NV+ (which I believe runs Linux), and accessed (for tag editing) from Windows XP SP3 via 802.11g, so that's a possible contributor. Where are your music files stored in relation to the computer on which you're working and running Mp3tag?Jim, I don't think dbpoweramp is dumb enough to do this. I've only ever known EAC to add ID3v2 tags to FLAC files. Use Mp3tag's filtering ability (F3) to only work on the FLAC files that have these extra ID3v2 tags. Make sure that you're not trying to cut/paste tags on your entire file library. If your files are on a Windows server on which you can run a remote desktop session then it may be worthwhile installing Mp3tag on that system also for the occasional whole-library operation. I've also seen some unexplained slowness when working from Windows and doing file operations on files stored on a *nix file server or NAS. For example, embedding cover art will usually be slow. This isn't generally done except when adding data at the beginning of a file that can't fit into the slack space of the vorbis comment block. If it's _very_ slow then it often means that the entire files had to be rewritten. Presumably a setting in MM or dbPowerAmp.Where are your music files stored in relation to the computer on which you're working and running Mp3tag? If they're on a network file server or NAS it will generally be a little slower, although I recently made some wholesale changes to 25,000 files on my server without a problem. Now to figure out how all the ID3v2 stuff gets in in the first place. MP3Tag is still very slow to delete tags, but I can do this piecemeal.
0 kommentar(er)
