search for: vorbis_com

Hi all, I tend to compile my code with all GCC warnings turned on. However, when I do this : vorbis_comment_add_tag(&vdata->vc,"ENCODER","libsndfile"); I get the following warning messages: warning: passing argument 2 of 'vorbis_comment_add_tag' discards qualifiers from pointer target type warning: passing argument 3 of 'vorbis_comment_add_tag...

I was looking over the comment manipulations routines defined in vorbis/codec.h and info.c and I noticed that each "char *" could/should really be defined as "const char*". Is it expected that this will change or was it defined like this for reason? void vorbis_comment_add(vorbis_comment *vc, char *comment); void vorbis_comment_add_tag(vorbis_comment *vc, char *tag, char *contents); char *vorbis_comment_query(vorbis_comment *vc, char *tag, int count); int vorbis_comment_query_count(vorbis_comment *vc, char...

...this and re-visiting some of this realloc() > stuff. I noticed that your patch removes the call to vorbiscomment_entry_array_delete_() in FLAC__metadata_object_vorbiscomment_resize_comments() function, and I think that it reintroduces one place of a potential memory leak: 'object->data.vorbis_comment.comments' is a pointer to an array of FLAC__StreamMetadata_VorbisComment_Entry structs, and these structs contain pointers. So it's necessary to free all 'object->data.vorbis_comment.comments[i].entry' pointers before freeing 'object->data.vorbis_comment.comments'...

...le(LC_ALL, 0)); + if (0 == saved_locale) + return false; + setlocale(LC_ALL, "C"); + if(0 <= (reference_offset = FLAC__metadata_object_vorbiscomment_find_entry_from(block, /*offset=*/0, (const char *)GRABBAG__REPLAYGAIN_TAG_REFERENCE_LOUDNESS))) (void)parse_double_(block->data.vorbis_comment.comments + reference_offset, reference); if(0 > (gain_offset = FLAC__metadata_object_vorbiscomment_find_entry_from(block, /*offset=*/0, (const char *)(album_mode? GRABBAG__REPLAYGAIN_TAG_ALBUM_GAIN : GRABBAG__REPLAYGAIN_TAG_TITLE_GAIN)))) - return !strict && grabbag__replaygain_...

I passed a valid FILE* (from fopen() with "rb") and the address of an OggVorbis_File struct, but an access violation occured when ov_open is called. I have enabled the Multithreaded, but it still doesn't fix the problem. I look at the vorbis_comment.exe source and I see vcedit_open() function and other vcedit_*() functions everywhere. I am assuming that there is known issue with VC and ov_open that's why vorbis_comment is using the edited version. I don't know if I should use these functions or not. Or maybe I missed something? do...

...-1754,20 +1754,24 @@ found_vc_block = true; } while(!found_vc_block && FLAC__metadata_iterator_next(iterator)); - /* create a new block if necessary */ - if(!found_vc_block && operation->type == OP__SET_VC_FIELD) { - block = FLAC__metadata_object_new(FLAC__METADATA_TYPE_VORBIS_COMMENT); - if(0 == block) - die("out of memory allocating VORBIS_COMMENT block"); - while(FLAC__metadata_iterator_next(iterator)) - ; - if(!FLAC__metadata_iterator_insert_block_after(iterator, block)) { - fprintf(stderr, "%s: ERROR: adding new VORBIS_COMMENT block to metadata,...

...block, unsigned block_length); static FLAC__Metadata_SimpleIteratorStatus read_metadata_block_data_seektable_cb_(FLAC__IOHandle handle, FLAC__IOCallback_Read read_cb, FLAC__StreamMetadata_SeekTable *block, unsigned block_length); static FLAC__Metadata_SimpleIteratorStatus read_metadata_block_data_vorbis_comment_entry_cb_(FLAC__IOHandle handle, FLAC__IOCallback_Read read_cb, FLAC__StreamMetadata_VorbisComment_Entry *entry); -static FLAC__Metadata_SimpleIteratorStatus read_metadata_block_data_vorbis_comment_cb_(FLAC__IOHandle handle, FLAC__IOCallback_Read read_cb, FLAC__StreamMetadata_VorbisComment *blo...

I am using the standard Xiph.org FLAC encoder, but I couldn't find any option to update the meta-data mid-stream. Also the FLAC spec says, that it defines VORBIS_COMMENT as the only way to transmit meta-data information. This is the only officially supported tagging mechanism in FLAC. There may be only one VORBIS_COMMENT block in a stream. As such, when you state, that meta data is the domain of the encoder; this seems to ignore this fact, that there is no FLA...

...39;: - opt->encoding = strdup(optarg); - break; case 'G': opt->genre = realloc(opt->genre, (++opt->genre_count)*sizeof(char *)); opt->genre[opt->genre_count - 1] = strdup(optarg); @@ -646,7 +643,7 @@ static void add_tag(vorbis_comment *vc, oe_options *opt,char *name, char *value) { char *utf8; - if(utf8_encode(value, &utf8, opt->encoding) == 0) + if(convert_to_utf8(value, &utf8) >= 0) { if(name == NULL) vorbis_comment_add(vc, utf8); @@ -655,7 +652,7 @...

...GENERAL_VENDOR_STRING "Xiph.Org libVorbis 1.2.1RC2" + #define ENCODE_VENDOR_STRING "Xiph.Org libVorbis I 20080501" + /* helpers */ static int ilog2(unsigned int v){ int ret=0; *************** *** 457,464 **** } static int _vorbis_pack_comment(oggpack_buffer *opb,vorbis_comment *vc){ ! char temp[]="Xiph.Org libVorbis I 20080501"; ! int bytes = strlen(temp); /* preamble */ oggpack_write(opb,0x03,8); --- 460,466 ---- } static int _vorbis_pack_comment(oggpack_buffer *opb,vorbis_comment *vc){ ! int bytes = strlen(ENCODE_VENDOR_STRING);...

...eveloping code on OpenBSD. As it turns out, there is a bug in ogg123s use of strcspn(3) - it should never return 0 unless the '='-sign is the first character (quite unlikely). Claudio proposed a patch for our portstree to fix this issue, can someone have a look at the patch to ogg123's vorbis_comments.c (below) and add this fix to the vorbis-tools codebase ? I have sample OGG files giving this behaviour available upon request (for debugging purposes only), if needed. Thanks, Paul 'WEiRD' de Weerd ----- Forwarded message from Claudio Jeker ----- So ogg123 crashes when unknown co...

...ou all again, but I've been trying to wrap my head around the encoding process and I'm about to have an aneurysm :P I've gone through oggenc.c, encode.c, and audio.c and I think I have a basic idea of what happens. I got it down in pseudocode as follows: --- 1 get parameters 2 init vorbis_comment -- vorbis_comment_init() 3 init vorbis_info -- vorbis_info_init() 4 start encoding with info and params -- vorbis_encode_init() 5 init vorbis_dsp_state from info -- vorbis_analysis_init() 6 init vorbis_block from dsp -- vorbis_block_init() 7 init ogg_stream_state with serial -- ogg_stream...

...block, unsigned block_length); static FLAC__Metadata_SimpleIteratorStatus read_metadata_block_data_seektable_cb_(FLAC__IOHandle handle, FLAC__IOCallback_Read read_cb, FLAC__StreamMetadata_SeekTable *block, unsigned block_length); -static FLAC__Metadata_SimpleIteratorStatus read_metadata_block_data_vorbis_comment_entry_cb_(FLAC__IOHandle handle, FLAC__IOCallback_Read read_cb, FLAC__StreamMetadata_VorbisComment_Entry *entry); -static FLAC__Metadata_SimpleIteratorStatus read_metadata_block_data_vorbis_comment_cb_(FLAC__IOHandle handle, FLAC__IOCallback_Read read_cb, FLAC__StreamMetadata_VorbisComment *blo...

libFLAC has several places like this: if(0 == (ptr = realloc(ptr, size))) return false; which results in memory leaks if realloc fails (the old value of ptr is lost). The patch should fix this. -------------- next part -------------- A non-text attachment was scrubbed... Name: realloc_memleak_fix.patch Type: application/octet-stream Size: 6272 bytes Desc: not available Url :

Good afternoon, On Tue, 2019-08-13 at 14:26 +0200, bn at radio42.com wrote: > I am using the standard Xiph.org FLAC encoder, but I couldn't find any option to update the meta-data mid-stream. > Also the FLAC spec says, that it defines VORBIS_COMMENT as the only way to transmit meta-data information. > This is the only officially supported tagging mechanism in FLAC. There may be only one VORBIS_COMMENT block in a stream. > As such, when you state, that meta data is the domain of the encoder; this seems to ignore this fact, that there...

...t;)) flac->artist = e.get_field_value(); else if (!strcmp(e.get_field_name(), "TITLE")) flac->title = e.get_field_value(); } return true; } else return false; } When I run this code, I get a SEGV during get_comment because object_->data.vorbis_comment.comments is junk. Must I initialize it somewhere? Note that vc.get_num_comments returns 14, which I imagine is a correct number. The documentation isn't overly clear about how this works and it would be cooler if some basic examples could be provided. Thanks in advance for any help that ca...

It seems, that with FLAC and OPUS streams (not individual files) the song title (meta data) updates do not work. Also the ICEcast admin web interface isn’t working for FLAC and OPUS; while it is working for MP3, AAC as well as OGG streams. I.e. when sending a continuous FLAC or OPUS stream to an ICEcast server, it seems impossible to update the meta data mid-stream (like it works for MP3, AAC

...gt; > As long as you're breaking API compatibility, why not fix this? I pushed this out to 1.0.4. I plan to add a FLAC__FileEncoder and on top of that a FLAC__WAVEEncoder or something like that. > 3. 'metadata --remove-vc-all' corrupts the target file if there is > any > VORBIS_COMMENT block present. 'metadata' can still read the file, > but > decoding errors out with FLAC__STREAM_DECODER_ERROR_LOST_SYNC. This > seems to be permanent corruption: no further operations, including > removing the VORBIS_COMMENT block, will restore it. I found this recently...

Function FLAC__metadata_object_delete_data() in libFLAC/metadata_object.c: it frees a pointer, then assigns 0 to it. But it doesn't do it for data.vorbis_comment.comments and object->data.cue_sheet.tracks. The patch adds assignment to zero for them. -------------- next part -------------- A non-text attachment was scrubbed... Name: free_and_null.patch Type: application/octet-stream Size: 1000 bytes Desc: not available Url : http://lists.xiph.org/pipe...

This is *nothing* major, just a minor tweak that makes FreeStream's rebroadcast system work smoother. It is a patch for icecast CVS( checked out at 20040505 20:00UTC), That simply adds to format_vorbis.c the ability to read more vorbis_comment information (namely; comment, info and length) Hopefully this can be useful. -- Justin Zeigler, a.k.a. Barbicane (jzeigler@freestream.net) FreeStream Minority Whip (almost sounds important, don't it?) Peace, Love and Procrastination -------------- next part -------------- A non-text...