tags->artworkcount incorrect

[GoogleCodeExporter]

If there is more than one piece of artwork in a file, tags->artworkcount
still returns one, and if you open a file for modify, get and then store
the tags, it gets set to 1 in the file.  If you have a file with two pieces
of art, then run the code below, it will report 1 piece and after the
modify there will be only one.  (I check the number with atomicParsley).

#include <mp4v2/mp4v2.h>
#include <windows.h>

int main(int argc, char** argv)
{

    MP4FileHandle file = MP4Modify( argv[1], 0, 0);
    if( file == MP4_INVALID_FILE_HANDLE ) {
        printf( "MP4Modify failed\n" );
        return 1;
    }

    /* allocate structure */
    const MP4Tags* tags = MP4TagsAlloc();

    /* fetch data from MP4 file and populate structure */
    MP4TagsFetch( tags, file );
    printf("Cover art count %d\n", tags->artworkCount);
    MP4TagsSetName(tags, "This is the final test.");
    MP4TagsStore(tags, file);

    /* free memory associated with structure and close */
    MP4TagsFree( tags );
    MP4Close( file );

    return 0;

}

Original issue reported on code.google.com by danahins...@gmail.com on 20 Nov 2009 at 2:18

[GoogleCodeExporter]

It looks like the problem might be (and I'm waaay out of my depth here) that in
CoverArtBox::list, it calls genericGetItemsByCode( file, "covr" ) to get the 
artwork,
but in reality if there are two pieces of art, there's one covr atom with two 
child
data atoms representing the two pieces of art.

Original comment by danahins...@gmail.com on 20 Nov 2009 at 2:32

[GoogleCodeExporter]

Which version of mp4v2 are you seeing this issue with? The latest trunk 
*should* be working.

Looking at src/itmf/CoverArtBox.*

Original comment by eddyg.o....@gmail.com on 22 Nov 2009 at 11:18

[GoogleCodeExporter]

I have not analyzed the source but I can definitely confirm that this is a bug 
introduced between the unofficial v2.0 released in January and the current 
v1.9.1.  
All other tools, including itunes, agree with v2.0 and attempting to manipulate 
multi-image mp4s will lead to data loss or complete file corruption.

It is 100% reproducible:

% cd .../mp4v2-2.0-20090110/...

% .\mp4art.exe --version
mp4art - MP4v2 2.0-20090110

% ./mp4art.exe --list "Y:\FILE.mp4"
IDX     BYTES  CRC32     TYPE       FILE
----------------------------------------------------------------------
  0   1439270  666f3c3e  implicit   Y:\FILE.mp4
  1   1279714  e2c4f40a  implicit
  2   1352985  f9b1b93a  implicit
  3    666888  215c975c  implicit
  4   1884494  ff3e8afa  implicit

% cd .../mp4v2-2.0-20090110/...

% .\mp4art.exe --version 
mp4art - MP4v2 1.9.1

% .\mp4art.exe --list "Y:\FILE.mp4"
IDX     BYTES  CRC32     TYPE       FILE
----------------------------------------------------------------------
  0   1439270  666f3c3e  png        Y:\Movies\FILE.mp4

Original comment by CarlEd...@gmail.com on 23 Nov 2009 at 1:12

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

It looks like this bug has creeped back into trunk. Files that show multiple 
images in itunes only have a 
showCount of 1 in mp4info.

If I try to force iterate, e.g. ignore the count and increment the pointer 
anyway it segfaults.

Original comment by kru...@gmail.com on 26 Nov 2009 at 4:32

[GoogleCodeExporter]

should be fixed in r372 .
hopefully you guys can confirm and close-out this issue.

Original comment by Kona8l...@gmail.com on 30 Nov 2009 at 9:16

[GoogleCodeExporter]

Yep, this appears to fix it, I'll close the item.

Good to see you back Kona8blend.

Original comment by danahins...@gmail.com on 30 Nov 2009 at 10:09

[GoogleCodeExporter]

Well I would close this if I could only figure out how.  If someone with the 
proper
authority would close this, it's fixed.

Original comment by danahins...@gmail.com on 30 Nov 2009 at 10:11

[GoogleCodeExporter]

Original comment by Kona8l...@gmail.com on 1 Dec 2009 at 4:26

• Changed state: Verified

[GoogleCodeExporter]

This definitely fixes the bug.  Could I plea for a new source release under 
Downloads?  
The tools from the latest source archive available for simple download 
actively, 
silently and irrecoverably eat data from many mp4 files.  A source archive 
without this 
bug might save a lot of grief to people who do not run an SVN client.

Original comment by CarlEd...@gmail.com on 14 Dec 2009 at 5:58