flac dev - Sep 2006 - FLAC__metadata_simple_iterator_set_block corrupting Flac (ogg) stream?

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

two unfortunate problems:

1. ID3 is illegal on Ogg files; that will probably always be
2. the metadata editing API currently only works for native FLAC,
not Ogg FLAC yet; eventually I will get to fixing that

Josh


--- Marc Wan <marcwanlists@gmail.com> wrote:
> 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.
> > _______________________________________________
> Flac-dev mailing list
> Flac-dev@xiph.org
> http://lists.xiph.org/mailman/listinfo/flac-dev
> 

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com