stripping tags from FLAC

[Anthony Liu]

2010/3/17 Lukáš Lalinský <lalinsky at gmail.com>

> On Wed, Mar 17, 2010 at 7:03 AM, Anthony Liu <quadamage at gmail.com> wrote:
> > Hi, I edited the modified wma files with Mp3Tag, these attributes were
> > existing and empty.
> > After I used Mp3Tag to remove the asf tag, these attributes were no
> longer
> > existing.
> >
> > It is not a problem, I am just curious about it.
>
> Now I'm curious too. I'm really not sure what Mp3tag does.
>

Some code like:
    ASF::File file(  "I:\\test.wma" );
    ASF::Tag *asfTag = file.tag();
    asfTag->setAlbum( "album" );
    file.save();
will generate the above five empty attributes.


>
> > BTW, as someone mentioned a few days ago, I can not use Taglib to write
> > cover art attribute whose size is over 65536.
> >
> > Recently, I used Taglib to do some tests to read/write the cover art
> fields
> > of various audio tags,
> > it worked well with the id3v2, mp4 and ape tags and have some problems
> with
> > the "WM/Picture" attribute.
>
> Correct, this is not implemented yet. Can you please file a bug report
> on bugs.kde.org about it?
>
>
The following code is to write the cover art:

ASF::File file(  "I:\\test.wma" );
      ASF::Tag * Tag = file.tag();


      ByteVector picdata; // binary data from a picture jpg file

ByteVector data;  // the cover attribute data

           data.append( (char)0x03 ); // front cover

           DWORD size = picdata.size();

           data.append( ByteVector::fromUInt( size, false ) ); // picture
binary data size

           data.append( 'i' );

           data.append( (char)0 );

           data.append( 'm' );

           data.append( (char)0 );

           data.append( 'a' );

           data.append( (char)0 );

           data.append( 'g' );

           data.append( (char)0 );

           data.append( 'e' );

           data.append( (char)0 );

           data.append( '/' );

            data.append( (char)0 );

           data.append( 'j' );

           data.append( (char)0 );

           data.append( 'p' );

           data.append( (char)0 );

           data.append( 'e' );

           data.append( (char)0 );

           data.append( 'g' );

           data.append( (char)0 );   // mime type, wide-character
null-terminated string



           data.append( (char)0 );

           data.append( (char)0 );

           data.append( (char)0 );

           data.append( (char)0 );  // null description, wide-character
null-terminated string



           data.append( picdata );  // the actual picture data


           Tag.addAttribute( String("WM/Picture"),  ASF::Attribute(data) );

                  file.save();

I have no problem with the above code to write cover attribute whose size is
less than 65536, if the size is over 64kb, it will corrupt the wma file.
BTW, Taglib have no problem in reading the WM/Picture attribute.

List<ByteVector> pics = new List<ByteVector> ();
>
> bool big_pics = false;
>
> foreach (IPicture pic in value) {
>     ByteVector data = PictureToData (pic);
>     pics.Add (data);
>     if (data.Count > 0xFFFF)
>             big_pics = true;
>     }
>
> if (big_pics) {
>         DescriptionRecord [] records =
>         new DescriptionRecord [pics.Count];
>     for (int i = 0; i < pics.Count; i ++)
>             records [i] = new DescriptionRecord (
>                 0, 0, "WM/Picture", pics [i]);
>         RemoveDescriptors ("WM/Picture");
>         metadata_library.SetRecords (0, 0,
>             "WM/Picture", records);
>     } else {
>     ContentDescriptor [] descs =
>             new ContentDescriptor [pics.Count];
>         for (int i = 0; i < pics.Count; i ++)
>             descs [i] = new ContentDescriptor (
>                 "WM/Picture", pics [i]);
>         metadata_library.RemoveRecords (0, 0,
>             "WM/Picture");
>         SetDescriptors ("WM/Picture", descs);
> }
>

These lines are from Taglib Sharp project, I know little C#, however, I can
see some special work should be done if the size is over 0xFFFF, you can see
http://gitorious.org/~sde/taglib-sharp/sdes-clone/commit/7eb12f96a809259db58b3d5fba1646803694ca0b<http://gitorious.org/%7Esde/taglib-sharp/sdes-clone/commit/7eb12f96a809259db58b3d5fba1646803694ca0b>
Hope it will be useful to you.


> It is likely that Taglib does not support to read/write the
> > METADATA_BLOCK_PICTURE  of the flac and vorbis files,
> > do you have a plan to add these features?
>
> Note that this is only an issue for FLAC. Cover art in FLAC files is
> stored in a separate block type METADATA_BLOCK_PICTURE. On the other
> hand, Vorbis Comments store cover art in a vorbis comment named
> "METADATA_BLOCK_PICTURE" (according to the latest recommendation),
> which is something you already can do.
>
> --
> Lukas Lalinsky
> lalinsky at gmail.com
> _______________________________________________
> taglib-devel mailing list
> taglib-devel at kde.org
> https://mail.kde.org/mailman/listinfo/taglib-devel
>

Following the vorbis comment specification, I should use the
XiphComment::addField function, the first parameter is METADATA_BLOCK_PICTURE,
the second parameter should be the Base64 encoded picture binary block. If
the picture binary block contains some null characters, when calling the
addField function, the binary data will be converted to the TagLib::String,
will the conversion result in truncating the binary data?

I hope you will add the flac cover support, thank you!


-- 
Best Regards
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.kde.org/pipermail/taglib-devel/attachments/20100318/039f813c/attachment-0001.htm