> something simple like artist and save, the update file views correctly > If I take one of these new files, use explorer properties to change > vista (and show the proper album art), it appears corrupted on the PSP. > The problem I see is that while the new mp3 files look ok to windows > libraries to search through and copy the id3v1 and id3v2 tags. > will not preserve mp3 headers, I'm using perl and the excellent mp3::tag In writing scripts to manage my media libraries. Thanks again for an awesome perl library! I've found it immensely useful Solve the problem [or if I've done something wrong - it wouldn't be the Please let me know if there is anything you'd like me to test to help Works and the psp album art appears correctly and is no longer corrupted. Once I found this thread and added the above config line, everything Something simple like artist and save, the update file views correctly If I take one of these new files, use explorer properties to change Vista (and show the proper album art), it appears corrupted on the PSP. The problem I see is that while the new mp3 files look ok to windows Libraries to search through and copy the id3v1 and id3v2 tags. Will not preserve mp3 headers, I'm using perl and the excellent mp3::tag I found others reporting that the APIC frame must come last here: + my = grep Īfter applying this patch, itunes reads album art *and* all other tags + # grr APIC must be the last tag for iTunes. # with a simple sort the order of frames of one type is the order I applied theįollowing patch to ID3v2.pm, which pushes the APIC frame to the end of Of the other tags (title, album, year track etc). This means iTunes will read the cover art properly, but will not see any So the APIC tag comes first with basic song information filled in. MP3::Tag is currently implemented the tags are written in sorted order, Not recognize any tags that appear after the APIC frame. However, there is another quirky itunes annoyance that you have to workĪround if you embed album art using MP3::Tag. iTunes can read APIC frames added if they were created with It seems that the id3v23_unsync option you added does indeed fix this That iTunes and taglib can not read the tag. Taglib(amarok) definately CAN NOT read the tags unless the line isĬommented out of ID3v2.pm. Also the "eyeD3"Ĭommand line tool from the python eyeD3 package seems to be able to read Specifically, the id3info toolįrom id3lib seems to have no problems reading the tag. In addition, *some* tools *can* read the tags even without the line in If youĭo not attach an APIC frame then the tag is read properly by iTunes and Note that the problem only happens if attaching an APIC frame. I am using: itunes 4.9 on OS X to reproduce this, and amarok 1.3.6 Without any problems (including the cover art) in both amarok and itunes. In ID3v2.pm, and re-run bug.pl on the file. Then comment out the above mentioned line Strip the tag out of foo.mp3 using whatever method you like (I used Reproduce the problem (iTunes and amarok can not read the tag). Neither one will be able to read the tag. Once done, try to open the foo.mp3 file in either amarok or itunes. Run the attached script which will create an ID3v2 tag for the file and Get a mp3 file called foo.mp3 and a cover image called cover.png (in PNG > I need some code sufficient to reproduce your problem. If you need any additional information, please let me know. It would be nice if this could be fixed so that MP3::Tag could attach cover art. I am not sure what that line is supposed to do, but it seems like the sequence of bytes it is looking for in that regex probably are matched in the image data that I am attaching, so its modifying the image data and that results in a corrupted tag.įor now I am just leaving that line commented out so that I can create valid APIC tags with MP3::Tag. If I leave that line in, then the tags that MP3::Tag creates are corrupted and not readable by other programs (such as itunes, xmms, amarok etc). If I comment that line out, then the problem goes away and I am able to create APIC frames that are valid and can be read by other programs. It seems that in MP3::Tag::ID3v2, in as_bin(), this line is the culprit: I was not able to make MP3::Tag create a tag with an APIC frame without modifying MP3::Tag sources.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |