AFT Embedded Tagging: now on FLAC, Ogg/Vorbis, Ogg/FLAC, and Ogg/Speex!
I've blogged about Amarok File Tracking before and there's a lot of information about it on the wiki. For those that haven't heard about the goodness of embedded file tracking, check out those links. There are a couple pieces of good news, and one piece of bad news.
The good news: in current SVN (and thus 2.2) the amarok_afttagger executable will also now handle FLAC and various Ogg-contained formats. Another piece of good news - the amarok_afttagger executable is now contained in the amarok-utilities package, and thus can be run on headless machines without X! And lastly -- AFT now works with user playlists, so you can move your files around (keep in mind the caveats if you're not using embedded AFT tags) and your playlists will always stay current, in addition to statistics and The Playlist.
The bad news? Something is currently a bit broken somewhere deep inside with Observers which means that The Playlist will only update with the correct new URL once (the metadata observers seem to die after that). This doesn't seem to be AFT specific but rather seems like a bug that AFT is exposing. Closing Amarok and reopening it will cause the proper new URLs to be in the playlist. I'm working on trying to fix that.
(Important note: it writes into the FLAC Xiph comment. This is the only metadata type actually required by the FLAC spec, and thus is the proper place to put it, but a lot of FLAC files incorrectly only have ID3v2 tags, so depending on the tagger you're using you may only see one or the other.)
June 21st, 2009 - 08:12
Does AFT cover also when tracks are deleted from any media?
E.g.:
1) I download an album from Jamendo or BlocSonic or whatever
2) retag it and listen to it
3) delete it because I need space
4) re-download the album again.
Expected results: again tagging
“Wow, this is great” results: automagically using the tags that I used before, with all the statistics etc. etc.
And if the latter is the case, I think it would make sense if Amarok asked you whether you want to tags that came with the files (e.g. id3) to overwrite your (old) custom tags or if you would like your (old) tags to overwrite the tags in the files (e.g. id3).
In any case it’s great to hear progress on AFT :]
June 21st, 2009 - 13:56
Yes and no.
If you don’t have an embedded identifier in the file, then it generates an identifier based on properties of the file itself. So if the file you downloaded was exactly the same (in terms of for instance metadata and file size) then it would get the same tag and statistics and such could migrate.
However, if you put an embedded identifier in such a track, it becomes tricky, because if you don’t put the same embedded identifier in the file the next time you download it, AFT won’t recognize it. In this case, the proper thing to do would be to put the file in the *exact* same location with the same filename as before. During the collection scan it will notice the file there and update the stored identifier in the database. After this, you should be able to move it around and have the tracking follow.
There isn’t really a way to automagically populate files with old AFT identifiers (after all, if it does it based purely on path, you may have purposefully moved a different file there). If there was a way to always do this correctly, you wouldn’t actually need AFT at all.
If you read the caveats on the wiki page it will probably help to explain the behavior too.
June 21st, 2009 - 14:11
So in order for my usecase to work, I would have to:
* use the non-embedded (i.e. just use Amarok without the extra helper program)
* use the same download as before (which in the example of Jamendo, Magnatune etc. is not too hard)
* and not change the (e.g. id3) tags of the files themselves (which is a bit annoying, but not too much).
Right?
June 21st, 2009 - 14:14
Ooops, I didn’t want to bold that line …I wanted to use asterikses as bullets. My bad :\
June 21st, 2009 - 15:51
Well, that’s one way. (By the way, you can mix and match embedded and non-embedded files, they just have the various tracking characteristics per file.)
Alternately, you can use the helper program to implant UIDs each time you download it. As long as those files are then scanned in the same exact path as the final place they were scanned before deletion, then the database will be updated with the new unique ID value. Then you can move them wherever you like (but again, next time you download it the first scan would have to be in the same path as they were last in). Note that URL/uniqueid mappings don’t get deleted from the database, which means that even if they are first scanned somewhere else, if you then move them to the same location as the previously-deleted files were and they are scanned again, it’ll remap that particular URL to the new uniqueid value.
June 21st, 2009 - 16:06
Hmmm, when I get my new laptop (I’m currently homeless, so to say, since the old one finally died), I’ll test your suggestions. Thanks for explaining :]