m4a tagging support?

[Jochen Issing]

Michael,

thanks for the detailed information. I actually thought about the "solution" 
for implementation as well, although I didn't have such detailed information 
about nero and foobar2000; I just wanted to figure out, how it was done by 
Brian. Maybe, if I can finish it, you can review/check the implementation?

Best Regards,

jochen

On Saturday 16 September 2006 16:08, Michael wrote:
> Jochen Issing wrote:
> > [..]
> >
> > The hacks:
> > * take the whole moov-box, replace it with a free box and place it
> > afterwards the mdat box. This avoids recalculation of any offsets, though
> > it makes the structure of the mp4 file slightly worse. Anyway, the file
> > format is still conformant, but one wastes the size of a whole moov box.
> >
> > [..]
> >
> > Cheers,
> >
> > jochen
>
> Hi Jochen,
>
> First of all, thanks for all your hard work so far, I really appreciate it.
>
> I'd just like to warn you about a problem that might arise using above
> hack. Placing the moov after the mdat is strictly speaking not
> 'illegal', it is very unwise though. Some hardware players will only
> play when moov precedes mdat, not sure of any software players but it is
> likely.
>
> A bigger problem with this box order is streaming and sharing these
> files over LAN's. Sharing your personal music library across LAN's is
> increasingly popular. The same goes for streaming an audio file to a
> device that is (or connects to) a regular Hi-Fi set. Apple Airtunes is a
> very popular implementation of this and certainly not the only one. In
> these situations the receiving end expects the metadata to arrive first
> in the stream because it needs it to know what kind of audio data will
> be following.
>
> iTunes for instance will play files with this reverse order perfectly
> until someone wants to hear them remote or wants to stream it to an
> Airtunes device, then these tracks will simply not play.
>
> For this reason both the Nero encoder and Foobar2000 recently changed
> their box order to overcome this problem, it would suit taglib if it
> chose the most compatible path as well.
>
> Regards,
> Michael
> _______________________________________________
> taglib-devel mailing list
> taglib-devel at kde.org
> https://mail.kde.org/mailman/listinfo/taglib-devel

-- 
 jochen issing
 gpg-sig: 0A121BC8
 www.mcf-music.de
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 191 bytes
Desc: not available
Url : http://mail.kde.org/pipermail/taglib-devel/attachments/20060917/c38870ba/attachment.pgp