m4a tagging support?
jochen at mcf-music.de
Sun Sep 17 00:59:26 CEST 2006
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?
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
> 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.
> taglib-devel mailing list
> taglib-devel at kde.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 191 bytes
Desc: not available
Url : http://mail.kde.org/pipermail/taglib-devel/attachments/20060917/c38870ba/attachment.pgp
More information about the taglib-devel