search for: max_bitr

...the 1.0 build (static as well as the pre-built DLL from the distribution) and the CVS snapshot, same result. However, at 44.1kHz all bit rates seem to work. Any ideas? <p>2. In vorbisenc.c / vorbis_encode_setup_managed, there's a piece that reads: if(nominal_bitrate<=0.){ if(max_bitrate>0.){ nominal_bitrate=max_bitrate*.875; }else{ ... If only min_bitrate and max_bitrate are passed, and nominal_bitrate set to zero for "auto" mode, nominal_bitrate might actually end lower than min_bitrate (e.g. if min_bitrate == max_bitrate for "CBR" emulation)...

...-1 ); VBR: ret = vorbis_encode_init_vbr( &vorbisInfo, getInChannel(), getOutSampleRate(), getOutQuality() ); <p>Are these calls correct? What effect do the max_bitrate, min_bitrate parameters have in the CBR and ABR modes? When measuring performance, it seems that the ABR mode takes a lot more (about twice) processing power than VBR of even CBR. why is that? Thanks, <p>Akos <p><p>--- >8 ---- List archives: http://www.xiph.org/archiv...

...ast2, using DarkIce to generate the stream. I have found some peculiarities with the vorbis bitrates. In DarkIce, I call vorbis_encode_init() with about the following values: vorbis_encode_init( &vorbisInfo, 2, 44100, 96, 96, 96); which by all reasons should generate a 96 kb/s stream, as all max_bitrate, nominal_bitrate and min_bitrate are set to 96. Strangely enough, the generated stream's bitrate (according to XMMS and WinAmp) varies between 49 and 59. If I try to set the same bitrate to a low 24, I never get a stream below about 44 kb/s. Could anyone enlighten me on these strange behav...

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

> vorbis_encode_init( &vorbisInfo, 2, 44100, 96, 96, 96); > > which by all reasons should generate a 96 kb/s stream, as all > max_bitrate, nominal_bitrate and min_bitrate are set to 96. Strangely > enough, the generated stream's bitrate (according to XMMS and WinAmp) > varies between 49 and 59. Currently min and max are ignored by the library, since bounded bitrates aren't going in until rc3. Also, if you pick 96kb...

...e maximum possible bitrate instead of a target bitrate setting. This satisfies the streaming people, but means that for an ordinary user to set a bitrate he'll have to set the quality to 9.999999 *and* the maximum bitrate to whatever he wants. ie. If he sets quality to "near CD" and max_bitrate to "128" then he's most likely going to get 80kbs anyway. They'll have to think laterally to get winamp to say "128". Even if he/she figures it out they'll have selected "archive quality" from the menu so they'll be thinking "hey, this can do *...

...vorbis_encode_init() before to set the bitrate(s)? And what is a good default value for the "base_quality" parameter? I read on the mailing list that ABR use in Ogg Vorbis is not so good. Should I disallow the user to set the nominal bitrate in the winLAME UI? And does VBR (setting "max_bitrate" and "min_bitrate") work? btw: good work dev team! I've waited for RC3 for some weeks :-) bye Michael -- http://winlame.sourceforge.net <<-- the only *nice* windows UI for LAME :) http://sourceforge.net/projects/winlame <<-- sf project homepage contact: Michael...

Hi. I'd like to ask a little about where Ogg stands today when it comes to streaming audio. The VBR has been the main argument in the incompatibility for streaming but has this changed somehow or will it? Is there something else besides quick and large scaled bandwith usage variations and the difficulty of buffering, that could cause problems? CBR could be used but some people say that it