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 588148 - [id3demux] APIC tag not found mp3 file
[id3demux] APIC tag not found mp3 file
Status: RESOLVED FIXED
Product: GStreamer
Classification: Platform
Component: gst-plugins-good
0.10.15
Other Linux
: Normal normal
: 0.10.16
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2009-07-09 10:30 UTC by Benjamin Gaignard
Modified: 2009-08-07 15:58 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
test file with image not found by read-metadata (960.00 KB, audio/mpeg)
2009-07-09 10:33 UTC, Benjamin Gaignard
  Details
patch draft, not clean, but fonctionnal (3.12 KB, patch)
2009-07-10 15:54 UTC, Benjamin Gaignard
rejected Details | Review
MP3 with apic issue (282.63 KB, audio/mpeg)
2009-08-06 09:27 UTC, Benjamin Gaignard
  Details

Description Benjamin Gaignard 2009-07-09 10:30:22 UTC
sometime the image inserted in mp3 is not found by id3demux. 
With read-metadata test program the image tag doesn't appear.
EasyTag could find the image. I have check with an hexa editor APIC tag is present in the file.
In id3tags.c in function id3demux_id3v2_frames_to_tag_list the test 
if (frame_size > work->hdr.frame_data_size || strcmp (frame_id, "") == 0)
failed because frame_size is > work->hdr.frame_data_size.
Comment 1 Benjamin Gaignard 2009-07-09 10:33:27 UTC
Created attachment 138112 [details]
test file with image not found by read-metadata
Comment 2 Benjamin Gaignard 2009-07-10 14:52:23 UTC
id3 frame header describe the size of the frame as the size of unsynchronous data contain in this frame. if unsynchronisation flag is found id3v2 header we un-unsynchronouse all the data, the result is that we have "less" data in buffer than expected id3 frame header so the frame is drop.
A solution could to not un-unsynchronise all data when the flag is set in id3v2 header but only after get it out of the frame.
Comment 3 Benjamin Gaignard 2009-07-10 15:54:48 UTC
Created attachment 138201 [details] [review]
patch draft, not clean, but fonctionnal 

is this patch need more work to be clean and maybe the change done for APIC parse sohould be apply on all other tags
Comment 4 Benjamin Gaignard 2009-08-06 09:27:45 UTC
Created attachment 140003 [details]
MP3 with apic issue
Comment 5 Tim-Philipp Müller 2009-08-07 15:58:25 UTC
This should fix it:

 commit 2e05af387614b9850a9b0782e5ee1ab1a78362fd
 Author: Tim-Philipp Müller <tim.muller@collabora.co.uk>
 Date:   Fri Aug 7 16:02:23 2009 +0100

    id3demux: fix parsing of unsync'ed ID3 v2.4 tags and frames
    
    Reversing the unsynchronisation seems to work slightly differently
    for ID3 v2.3 tags and v2.4 tags: v2.3 tags don't have syncsafe frame
    sizes in the frame header, so the unsynchronisation is applied to
    the whole frame data including all the frame headers. v2.4 frames
    have sync-safe sizes, however, so the unsynchronisation only needs
    to be applied to the actual frame data, and it seems that's what's
    being done as well. So we need to undo the unsynchronisation on a
    per-frame basis for v2.4 tags for things to work properly.
    
    Fixes extraction of coverart/images from APIC frames in ID3 v2.4
    tags (#588148).
    
    Add unit test for this as well.


Sorry it took so long. Was pretty busy with other stuff.

(Your patch would've broken parsing of unsynced v2.3 tags IIRC.)