m4a/mp4 itunes files

[Jochen Issing]

On Monday 21 November 2005 11:49, Scott Wheeler wrote:
> On Friday 18 November 2005 23:48, Martin Aumueller wrote:
> > Hi all, hi Scott,
>
> First off, I'll be a bit slow at responding in general at the moment since
> I'm in the process of moving and don't have home internet at the moment.
>
> > On 11/18/05, Ismail Donmez <ismail at uludag.org.tr> wrote:
> > > On Friday 18 November 2005 21:21, Jochen Issing wrote:
> > > > [...]
> >
> > Wma support within amaroK lacks write support, while mp4/aac support
> > is feature complete (tag reading and writing). Handling of aac tags
> > requires libmp4v2, either from faad2 or from mpeg4ip. Faad2 fails to
> > read the tags it has written itself (except when cleaning and
> > rewriting all tags), whereas with mpeg4ip everything works nicely. But
> > as there are no distribution packages for mpeg4ip, I would welcome it
> > very much if there was support for mp4 tags within taglib not based on
> > any external libraries to make dependency hell a little friendlier a
> > place. And if you implemented mp4 tags independent of any external
> > library it would fit taglib much better and I would not hesitate to
> > include it within amaroK.
> >
> > As I read on this mailing list, Scott Wheeler is reluctant to include
> > support for mp4/aac as there are no formal standards for metadata on
> > these files and as he does not use this functionality and thus would
> > not be able to test and support it.
>
> Well more that they're not documented formats.  Well, WMA is, but the EULA
> on the spec basically rules out reading it for use in OSS implementations.
I heard today that itunes m4a is spec'd as well. But I don't know about the 
license yet, needs check...
>
> With mp4 previously I'd had no way of checking to see if they broke
> playback in "canonical" implementations -- i.e. iTunes.  However I do now
> have an iBook, so I could test things if there were an implementation.
>
> The "plugins" won't be integrated for several reasons:
>
> - the mp4 one uses an external library, which TagLib doesn't do
> - the WMA one is read only, which doesn't fit with the current TagLib
> generic interfaces (I may consider adding support for read only formats in
> 2.0) and the code as I recall is pretty hack-ish
> - In the latter I don't feel particularly confident that the sources are
> "clean" since if I remember correctly they come from the mplayer sources,
> which isn't exactly known for paying a lot of attention to licensing
>
> > Perhaps a solution for this situation is to extend the current plugin
> > architecture in a way such that taglib would automatically load shared
> > objects in certain places, so that implementing additional formats
> > becomes completely transparent to the application. And if taglib could
> > include a contrib directory for unsupported formats that would be even
> > nicer. Scott, what do you think of such an approach? Would you
> > consider extending the plugin architecture if I send you a patch?
>
> I'm quite reluctant to do so; I intentionally maintain a pretty
> conservative policy for TagLib inclusion since, well, people get pretty
> angry when things suddenly break their files.  At this point at least
> application authors have to specifically chose which things will be
> touching their users' files and in the case of amaroK it's fairly easy to
> reassign bug reports to them in the case that there are broken files and so
> forth.
>
> But a generic plugin system that used things just by virtue of them being
> installed seems like it could be a dangerous path.  Some formats are
> relatively easy to break (there was one TagLib version, fortunately very
> quickly fixed that broke all FLAC files since it was one byte off in
> writing things).
>
> From a users perspective they don't really care that "Oh, your files are
> broken because you have this plugin installed and it corrupted files by
> overriding the default handler..."  They just know that their files won't
> play anymore and they're pissed off.  ;-)
>
> Just following up on a couple of other questions that came up:
>
> - Like Allan I haven't seen a spec for mp4 metadata.  ID3 is indeed spec'ed
> out -- ID3v2 with formal specs, ID3v1 with informal, though it's so trivial
> that such isn't a big deal.
>
> - I'd consider a patch for the formats mentioned above, provided that they
> were fairly clean, don't use external libs, etc.
I really understand your objections and I can second some of them. What I am 
thinking about is a small standalone implementation without the use of 
external libs etc. But I need to prepare myself and check for former 
implementations. I will not give you untested files, of that you can be sure.
Do you have sth like coding rules, etc or is it mentioned in the code 
somewhere?

Best Regards,

jochen
-- 
 jochen issing
 gpg-sig: 0A121BC8
 www.isign-softart.de