MP4 atoms incorrectly showing as non-null empty strings (e.g., "aART" and "\251wrt" atoms)
Lukáš Lalinský
lalinsky at gmail.com
Wed Apr 3 12:04:33 UTC 2013
With AtomicParsley I get this:
lukas at gurgle:~/code/taglib$ AtomicParsley a.m4a -t
Atom "trkn" contains: 21 of 29
Atom "disk" contains: 1 of 2
Atom "gnre" contains: R&B
Atom "stik" contains: Normal
Atom "©alb" contains: DJMAX TECHNIKA 3 ORIGINAL SOUNDTRACK
Atom "aART" contains: PENTAVISION
Atom "----" [com.apple.iTunes;ARRANGER] contains: 3rd Coast
Atom "©ART" contains: 3rd Coast
Atom "©wrt" contains: 3rd Coast
Atom "cprt" contains: ℗&©2011 PENTAVISION Corp.
Atom "----" [com.apple.iTunes;COVER ART DIMENSION] contains: 720
Atom "----" [com.apple.iTunes;DISCID] contains: 970D3F1D
Atom "----" [com.apple.iTunes;GENRE DJMAX] contains: R&B Slow
Atom "----" [com.apple.iTunes;iTunSMPB] contains: 00000000 00000840
00000168 0000000000524658 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000
Atom "----" [com.apple.iTunes;LABEL] contains: PENTAVISION
Atom "----" [com.apple.iTunes;LYRICIST] contains: JC
[01:53:33]Rhyme over these processed beats - back to back on the DJMAXg
Atom "----" [com.apple.iTunes;LYRICS LANGUAGE] contains: English
Atom "----" [com.apple.iTunes;PACKAGING] contains: Super Jewel Box
Atom "----" [com.apple.iTunes;PERFORMER] contains: vocal: So Fly / rap: JC
Atom "----" [com.apple.iTunes;RIPTOOL] contains: ExactAudioCopy v1.0b2
Atom "©nam" contains: My Heart, My Soul
Atom "©too" contains: qaac 1.39, CoreAudioToolbox 7.9.7.9, AAC-LC Encoder,
TVBR q91, Quality 96
Atom "©day" contains: 2011-10-07
Atom "----" [com.apple.iTunes;BAND] contains:
Atom "©wrt" contains:
Atom "covr" contains: 1 piece of artwork
So yes, it does contain ©wrt multiple times. I'm not sure if that's
expected to happen and what would be the best way for TagLib to handle it,
but currently it uses only the last entry. Could you check with iTunes if
it can read the composer tag?
The printing issue is expected. What you get from ByteVector::data is not
NULL-terminated, so you can't use simple %s with it.
On Wed, Apr 3, 2013 at 12:28 PM, Duke Yin <yindesu at gmail.com> wrote:
> I've added log statements to the 1.8 final source code and determined that
> when an MP4 file/tag is constructed, the tag is constructed multiple times.
>
> Test file:
> http://dl.dropbox.com/u/22586935/test/121%20My%20Heart%2C%20My%20Soul.m4a
>
> Log change:
> https://github.com/taglib/taglib/blob/stable/taglib/mp4/mp4tag.cpp#L174
> In ParseText function,
> Added: printf("Inserted %s : %s.",
> atom->name.data(),
> value.toString(" ; ").toCString(true));
>
> Full log:
> http://pastebin.com/EYba1uDL
>
> Order of tags read:
> 04-03 03:13:29.545: Inserted �alb�������� :
> 04-03 03:13:29.545: Inserted aART�������� :
> 04-03 03:13:29.555: Inserted �ART�������� :
> 04-03 03:13:29.555: Inserted �wrt�������� : Good (1st)
> 04-03 03:13:29.555: Inserted cprt�������� :
> 04-03 03:13:29.555: Inserted �lyr�������� :
> 04-03 03:13:29.555: Inserted �nam�������� :
> 04-03 03:13:29.565: Inserted �too�������� :
> 04-03 03:13:29.565: Inserted �day�������� :
> 04-03 03:13:29.565: Inserted �wrt�������� : BAD blank! (2nd)
> 04-03 03:13:29.585: Inserted �alb: :
> 04-03 03:13:29.585: Inserted aARTo :
> 04-03 03:13:29.585: Inserted �ARTp :
> 04-03 03:13:29.585: Inserted �wrt0 : Good (3rd)
> 04-03 03:13:29.585: Inserted cprt :
> 04-03 03:13:29.595: Inserted �lyr, : (longer by 7-8 chars compared to the
> first "?lry" atom)
> 04-03 03:13:29.595: Inserted �nam in my h :
> 04-03 03:13:29.595: Inserted �toodo it to :
> 04-03 03:13:29.595: Inserted �dayuals[00 :
> 04-03 03:13:29.595: Inserted �wrtack to b : BAD blank! (4th)
>
>
> As you can see, Composer was read 4 times, with the last read being a
> blank string. Additionally, atom's name gets garbled after the first 4
> characters.
>
> Can anyone explain what's going on here? Bad m4a file? Bug in TagLib?
> Broken behavior because of compiling for Android?
>
> Thanks,
> Duke
>
> _______________________________________________
> taglib-devel mailing list
> taglib-devel at kde.org
> https://mail.kde.org/mailman/listinfo/taglib-devel
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/taglib-devel/attachments/20130403/6d42c662/attachment.html>
More information about the taglib-devel
mailing list