After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 525602 - Tags Imported with Junk before Title, Artist & Album.
Tags Imported with Junk before Title, Artist & Album.
Status: RESOLVED FIXED
Product: banshee
Classification: Other
Component: Importing
0.98.2
Other All
: Normal normal
: 1.2
Assigned To: Banshee Maintainers
Banshee Maintainers
Depends on:
Blocks:
 
 
Reported: 2008-04-01 18:14 UTC by Drew Ogle
Modified: 2009-01-04 16:47 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
First 4s of a mp3 file which is an example of this problem. (50.00 KB, audio/mpeg)
2008-07-29 15:40 UTC, Drew Ogle
  Details
Fix Data Length Indicator handling. (367 bytes, patch)
2008-07-30 13:12 UTC, Drew Ogle
none Details | Review

Description Drew Ogle 2008-04-01 18:14:40 UTC
Please describe the problem:
I have 4 cds worth of files that were ripped via Sound Juicer, which have been ripped in MP3 format. 

All mangled text starts with ;;[0x0?][0x03],
with the ? varying and [ ] being one character.

This has been verified to occur with a clean install.

Steps to reproduce:
1. Rip CDs into MP3s via Sound Juicer
2. Import into Banshee
3. Problem is seen.


Actual results:
The tags have junk in them.

Expected results:
The tags are shown as they appear to be in the MP3 file

Does this happen every time?
Yes.

Other information:
Comment 1 Gabriel Burt 2008-04-08 02:43:14 UTC
Can you determine what charset the tags are?
Comment 2 Andrew Conkling 2008-07-29 12:33:15 UTC
Closing this bug report as no further information has been provided. Please feel free to reopen this bug if you can provide the information asked for.
Thanks!
Comment 3 Drew Ogle 2008-07-29 14:41:43 UTC
Sorry for taking so long.

Parsing the file by hand reveals that in the ID3v2.4.0 section,

the data in the frames has 'data length indicator' flag set, and this offsets the textual data of the tag off by 4 ( as per http://www.id3.org/id3v2.4.0-structure ) )
Comment 4 Andrew Conkling 2008-07-29 15:32:12 UTC
OK, thanks for replying. Have you tested in 1.0 or SVN to examine whether this is still a problem now? Also, which version of taglib-sharp do you have on your system?
Comment 5 Drew Ogle 2008-07-29 15:35:52 UTC
Just checked with 1.0.0 today.

Problem still exists.
Comment 6 Drew Ogle 2008-07-29 15:40:33 UTC
Created attachment 115500 [details]
First 4s of a mp3 file which is an example of this problem.

File which exhibits the problem.
Comment 7 Drew Ogle 2008-07-29 16:24:56 UTC
Ok, so this is a bug in taglib#.

A simple C# testcase is showing this to be the case.
Comment 8 Drew Ogle 2008-07-30 13:12:08 UTC
Created attachment 115560 [details] [review]
Fix Data Length Indicator handling.

Attaching here because Taglib-sharp has no bugzilla.
Comment 9 Miika Kankare 2008-12-21 20:23:33 UTC
I'm experiencing the same as described in the bug report. Haven't used Sound Juicer though.

If this is a bug with Taglib-sharp, can it be resolved somehow?

My files show up fine in other music players (tried bmpx and exaile).
Comment 10 Bertrand Lorentz 2009-01-04 16:47:53 UTC
It looks like this was fixed by Gabriel in taglib-sharp svn :
http://anonsvn.mono-project.com/viewvc/trunk/taglib-sharp/src/TagLib/Id3v2/Frame.cs?r1=92562&r2=121568

Feel free to re-open this bug if it is not the case.