[mp3togo] audiotags diff

[Justus Pendleton]

sim wrote:
> There are a few issues with it though:

I didn't expect it to be perfect on the first try :)

> First: The output files are not actually tagged on my machine.

On my machine I've noticed that they are being tagged but certain 
programs are unable to read the tags. For instance, using mutagen or 
foobar2000 I can re-read the tags but if I use id3v2 it doesn't find 
anything. I believe this is because mutagen is writing a relatively 
modern version of id3v2 and many older tag reading programs don't 
properly handle them.

> Second: flac files throw an ErrorUnknownFileType error. wav input
> files throw the same exception. This is not good as wav is a supported
> input format and of course has no provision for metadata tags.

I'll have to wait until tomorrow to look at this. My home debian machine 
is a little underpowered for running lame.

> The old Tags class attempts to guess the right values for untagged
> files, if the files are within a 'usual' directory structure, the
> guesses made are fairly good.

I noticed that and meant to mention I hadn't reimplemented it but 
forgot. Ideally "guess tags from filename" should be a user configurable 
option but then mp3togo begins to move into the territory of a general 
purpose tagger. Personally I would rather keep a lot of that 
functionality out -- easytagger, exfalso, and others already do an 
excellent job of that kind of thing -- but obviously it is your software 
and your final decision :)

> My music archive is in fairly good shape, but I can envision angry
> limewire users deleting mp3togo in frustration over this.

If it were up to me I'd take a fascist stand and demand people have good 
tags ;-) But I see what you're saying about the usefulness of trying to 
guess tags. Another possibility -- in addition to guessing based on 
directory structure/filename -- is musicbrainz support. But, again, this 
starts encroaching on the territory of full-fledged tagging program.

> Third: The audiotags library needs to be properly packaged.

Certainly. I wanted to get some feedback and a little use before doing 
that. Also, I don't think it makes much sense to "release" it until the 
next version of mutagen is out.

> It is not difficult to set up distutils for a pure python source
> package and packaging for Debian is not much harder. I'd be happy to
> do this myself, but it must be done before mp3togo will be releasable.

I learned long ago that when someone else offers to do something for 
you, you should take them up on it ;-)

> Fifth: Looking at the audiotags source, the modules named for file
> types are just boilerplate around the mutagen library. I'm not sure
> exactly what it all does yet, but there is a prominent warning in the
> comment for AudioFile declaring that the function is not thread safe.
> This is not a problem right now, but I've been trying to keep
> everything thread safe in anticipation of a GUI front end and other
> possible future uses.

Yes, you cannot call the function "audiotags.AudioFile(filename)" from 
multiple threads and have it perform reliably in the face of errors. 
This is because of the way it stores the exception error (in a global 
variable, essentially). I'm not entirely sure why QL chose that approach 
  for handling errors instead of simply propagating the exception.

> The abstractions that present a uniform interface to the various file
> formats in __init__.py are serving the same function that the Tags
> class served, they hide the details of the tag formats and make access
> available in a standard way. It seems to me that this boilerplate
> around mutagen could just as well go in Tags replacing the old
> boilerplate around ID3, ogg.vorbis and metaflac.

The QL code also includes ways to access AAC, musepack, and wavpack 
files via ctypes. I have numerous files in AAC and musepack and thus 
having mp3togo support those is a high priority for me. It is true, 
whether it lives in tags.py or a separate package it is doing 
essentially the same thing.

Justus