[Flac-dev] FLAC__metadata_simple_iterator_set_block corrupting Flac (ogg) stream?

[Marc Wan]

Hey!

  So, I'm clearly doing something wrong, because I've written a program to
view and modify the comment tags in a FLAC file, which appears to be
embedded an Ogg stream.  This particular file also has ID3 headers at the
beginning, but I was planning on ignoring those and fixing them up using
some ID3 code later on ...

  Now, to read the comments is quite simple:

  FLAC__metadata_get_tags(fileName, &tagData);
  ...
  ..
  .
  FLAC__metadata_object_delete(tagData);



  For writing to the file, however, I do something along the following lines
(error code stripped out to keep things shorter), this is pretty much as the
flac documentation suggests:

        result = FLAC__metadata_simple_iterator_init(iterator, fileName,
FALSE, FALSE);

        /**
         * Zip through the file for the vorbis comment section.
         */
        while (FLAC__metadata_simple_iterator_get_block_type(iterator) !=
FLAC__METADATA_TYPE_VORBIS_COMMENT)
        {
            result = FLAC__metadata_simple_iterator_next(iterator);
        }

        /**
         * Get the current block and write out the new values for it.
         */
        metaData = FLAC__metadata_simple_iterator_get_block(iterator);

        /**
         * Save the strings out.
         */
        [self saveCommentsToIterator: metaData];

        /**
         * Now, save out the block.
         */
        result = FLAC__metadata_simple_iterator_set_block(iterator,
metaData, TRUE);

        FLAC__metadata_simple_iterator_delete(metaData);


   the saveCommentsToIterator method just updates the "entry" and "length"
fields of those comment entries in the vorbis_comments that have changed.
(is that perhaps not correct?) .... hexdumping the file after writing seems
to show a new comment block with the appropriate new values in it ...

  The problem, which the docs hinted at:

  - if the comments are shorter or not much longer:  everything works great
  - if the comments are much longer:  the file appears to be rewritten.
hexdump -C shows that the ID3 header is destroyed (not a problem, really)
and the file now has a 'fLaC' binary signature at the top.  (again, no
problem -- other FLAC files appear to have this).

  This new file, however, cannot be read in by the above code using
FLAC__metadata_get_tags.  It barfs internally while trying to read some
metadata chunks from the file (not the first one, either).

  Any idea why the newly written file cannot be read by my program any
more?  Programs that play audio, such as VLC, can still play the FLAC file
just fine ....

  Any pointers to what I'm doing wrong would be greatly appreciated.

  Thanks,
  marc.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.xiph.org/pipermail/flac-dev/attachments/20060907/3ad1d5df/attachment.htm