search for: bitrate_upper

With this patch, ogginfo will display bitrate information (upper/lower/nominal/average bitrate). It is patched against today's CVS code (main branch). I am also working on true VBR support in oggenc (the user can specify the minimum & maximum bitrate) and will send a patch when it's done. <HR NOSHADE> <UL> <LI>application/x-gzip attachment: ogginfo-diff.gz

...eams are great - it lets this norteamericano get his fill of BBC Radio 1's Essential Mix. Unfortunately, saved streams aren't seekable. Running ogginfo on the stream data gives: erial=1626603590 header_integrity=pass vendor=Xiphophorus libVorbis I 20011231 version=0 channels=2 rate=44100 bitrate_upper=none bitrate_nominal=128031 bitrate_lower=none stream_integrity=fail stream_truncated=true header_integrity=fail Reported length varies; Winamp seems to think this is 6653:18 in length, while most tools think it has zero length. One would think that, seeing as the stream decodes nicely, it should...

...eams are great - it lets this norteamericano get his fill of BBC Radio 1's Essential Mix. Unfortunately, saved streams aren't seekable. Running ogginfo on the stream data gives: erial=1626603590 header_integrity=pass vendor=Xiphophorus libVorbis I 20011231 version=0 channels=2 rate=44100 bitrate_upper=none bitrate_nominal=128031 bitrate_lower=none stream_integrity=fail stream_truncated=true header_integrity=fail Reported length varies; Winamp seems to think this is 6653:18 in length, while most tools think it has zero length. One would think that, seeing as the stream decodes nicely, it should...

...vs. AMD Athlon), would it? There's no CPU specific optimisations yet, e.g. selecting 3dnow instructions for the latter. Does 129 and 124kbit look about right for a -b setting, does one get that kind of range? Here I'm missing that "encoding parameters" tag. Hehe. Both have: bitrate_upper=none bitrate_nominal=128031 bitrate_lower=none Thanks, Hugo --- >8 ---- List archives: http://www.xiph.org/archives/ Ogg project homepage: http://www.xiph.org/ogg/ To unsubscribe from this list, send a message to 'vorbis-request@xiph.org' containing only the word 'unsubscribe'...

...this thread it shouldn't be trusted too much. Just for reference, I saved a streamed ogg and got this: --------------------------------- E:\>ogginfo radio4.ogg filename=radio4.ogg erial=1037942235 header_integrity=pass vendor=Xiphophorus libVorbis I 20011217 version=0 channels=2 rate=44100 bitrate_upper=none bitrate_nominal=96016 bitrate_lower=none stream_integrity=pass bitrate_average=65 length=182692.561270 playtime=3044:52 stream_truncated=true total_length=182692.561270 total_playtime=3044:52 <----------------- what winamp also thinks. E:\> -------------------...

...xample what would I need to do to see what a 44.1Khz mono track sounds like at 50kbits/sec (instead of 68). I've had a look at the source code, but can't really see where a datarate control would fit in. As far as I can tell from a recent CVS snapshot, none of the files are looking at the bitrate_upper and bitrate_lower variables in a meaningful way. Is anyone else looking at this? Thanks, - -Jesse p.s. please CC me on reply, I'm not yet on the list ------- End of Forwarded Message --- >8 ---- List archives: http://www.xiph.org/archives/ Ogg project homepage: http://www.xiph.org/ogg/...

...xample what would I need to do to see what a 44.1Khz mono track sounds like at 50kbits/sec (instead of 68). I've had a look at the source code, but can't really see where a datarate control would fit in. As far as I can tell from a recent CVS snapshot, none of the files are looking at the bitrate_upper and bitrate_lower variables in a meaningful way. Is anyone else looking at this? Thanks, - -Jesse p.s. please CC me on reply, I'm not yet on the list ------- End of Forwarded Message --- >8 ---- List archives: http://www.xiph.org/archives/ Ogg project homepage: http://www.xiph.org/ogg/

After accidentally ogginfo-ing a WAV file, I'm wondering if there's any reason I shouldn't commit my fix that breaks out of the current file test if header integrity fails. Is there any case where the header integrity will fail but there is still any useful information to get out of the stream? I don't think so... -- Kenneth Arnold <ken@arnoldnet.net> - "Know

...ack_buffer *opb){ 196 codec_setup_info *ci=vi->codec_setup; 197 if(!ci)return(OV_EFAULT); 198 199 vi->version=oggpack_read(opb,32); 200 if(vi->version!=0)return(OV_EVERSION); 201 202 vi->channels=oggpack_read(opb,8); 203 vi->rate=oggpack_read(opb,32); 204 205 vi->bitrate_upper=oggpack_read(opb,32); 206 vi->bitrate_nominal=oggpack_read(opb,32); 207 vi->bitrate_lower=oggpack_read(opb,32); 208 209 ci->blocksizes[0]=1<<oggpack_read(opb,4); 210 ci->blocksizes[1]=1<<oggpack_read(opb,4); 211 212 if(vi->rate<1)goto err_out; 213 if(vi-&gt...

...Average bitrate: 132.944968 kbps Logical stream 1 ended Warning: Hole in data found at approximate offset 3530268 bytes. Corrupted ogg. <p>---------- ogginfo rc3 erial=715851111 header_integrity=pass <snip> vendor=Xiphophorus libVorbis I 20010813 version=0 channels=2 rate=44100 bitrate_upper=none bitrate_nominal=128000 bitrate_lower=none stream_integrity=pass bitrate_average=132758 length=212.240000 playtime=3:32 stream_truncated=false total_length=212.240000 total_playtime=3:32 ----------------- What could cause this? (Other than physical data loss.) This file never went anywhere....

Just got around to compiling RC3 under beos and came across an anomaly when using managed bitrates. I haven't changed the code for the beos encoder but I now get double the bitrates so vorbis_encode_init(&vi,mediaFormat.u.raw_audio.channel_count,(long)mediaFormat.u.raw_audio.frame_rate , -1, 128000, -1); now gives me vorbis files that average around 325 - 350. Is this now the correct