is stereo or joint stereo optimum for encoding at 192kbps? i notice that
mp3enc 3.1 stops using joint stereo at 192kbps. im looking towards music
archival with emphasis on maintaining the higher frequencies (16khz+),
should 160kbps be enough? any input? recommenations on stereo modes and
bitrates
I believe the fraunhofer codec in the new Musicmatch is identical to the one
in Nero. I also remember reading that the new fraunhofer hi speed VBR is
very shabby quality compared to the older versions.
I would like to weigh in on the side of leaving VBR settings alone. LAME is
different and bet
>I used the default settings for all encoders in the constant bitrate
test. Actually, there are not many knobs for the Fraunhofer codec c't
gave me (the one in MusicMatch).
>I don't like the Fraunhofer codec very much for music. It is excellent
for speech, but it makes music sound flat.
>Well,
Your rtp thing probably encodes one frame per packet. My little utility
grabs 1k of data and transmits it.
_J
In the new year, Felix von Leitner wrote:
> > also mpg123 seems to not like catching a stream from stdin. The only way
> > this works is if mpg123 gets a frame on stdin with nothing el
On Wed, 2 Feb 2000, Ross Levis wrote:
> But as Gabriel Bouvigne argued, you are limiting best quality to the lowest
> number available -- 0. What do you do if a better quality mode is created?
> Go negative? :)
Shift them all up. Newer lames will be a bit slower for people not taking
the best q
Thus spake Cavallo de Cavallis ([EMAIL PROTECTED]):
> > Comparing blade at 160 with Xing at 128 is like comparing warm pepsi to
> > cold coke.
> so blade sucks in such evident way ?
Yes.
I is like lame without the patches ;)
Please read the lame changelog, just the patches in the last year
affect
> also mpg123 seems to not like catching a stream from stdin. The only way
> this works is if mpg123 gets a frame on stdin with nothing else before it,
> like a partial frame. If the encoding changes, like say if it wanted to
> change from 128k to 256k, mpg123 simply ignores the frames. so if mp
Jeremy Hall wrote:
>ok, and so that -H is consistent with -V, make it do likewise.
But as Gabriel Bouvigne argued, you are limiting best quality to the lowest
number available -- 0. What do you do if a better quality mode is created?
Go negative? :)
Ross.
--
MP3 ENCODER mailing list ( http://ge
> > > Fraunhofer, lame, Xing, (long pause) bladeenc
> > so blade is so shitty ? doh i have used it for a while, btw at 160, probably
> > better than xing @128 i used before
>
> Comparing blade at 160 with Xing at 128 is like comparing warm pepsi to
> cold coke.
so blade sucks in such evident
not for stdin/stdout it wouldn't be useful.
_J
In the new year, Ross Levis wrote:
> Don Melton wrote:
>
> > --qual low equivalent to highq=9
> > --qual normal " " " 5
> > --qual high " " " 2
>
> The idea to create secondary options
also mpg123 seems to not like catching a stream from stdin. The only way
this works is if mpg123 gets a frame on stdin with nothing else before it,
like a partial frame. If the encoding changes, like say if it wanted to
change from 128k to 256k, mpg123 simply ignores the frames. so if mpg123
dec
-H 0 : run as slow as possible
-H 9 : run as fast as possible
_J
In the new year, Greg Maxwell wrote:
> On Wed, 2 Feb 2000, Robert Hegemann wrote:
>
> > Greg Maxwell schrieb am Die, 01 Feb 2000:
> > > On Tue, 1 Feb 2000, Jeremy Hall wrote:
> > >
> > > > but then you're in conflict with VBR.
>
> People will select
> the quality based not on what features are enabled/disabled
> (which is unimportant, really) but on what their perceived
> gain will be:
> 0 = lowest quality, regardless of actual implementation
> 9 = highest quality
> If we add something that improves quality over the curre
0..9 is a good scale. If we need to add
features at the top or bottom end, we
can compress that option toward the default
(4?), i.e. change the old 9 setting to 8
and add a new setting 9. People will select
the quality based not on what features are enabled/disabled
(which is unimportant, really)
Thus spake Peter Olufsen ([EMAIL PROTECTED]):
> But isen't it a bit unfair to compare it at 96 when Blade always
> encode stereo with no band-21 cutoff, and no and all the others joint
> stereo with band-21 cutoff ?
I don't think so.
One of the main improvements of layer 3 over layer 2 is joint
On Wed, 2 Feb 2000, Robert Hegemann wrote:
> > We orignally used V to set the number of bands allowed to be 'over'.
> > When
> > we changed that, we should have V.
>
> Why? Only to confuse users?
> And the idea of V hasn't changed.
But it's meaning did change. V used to mean: The number of scal
> Doesn't xmms use a different engine? I don't use xmms.
> I use mpg123 0.59r, too, and it repeatedly bombs on "-v -V 0" encoded
> songs. A friend of mine apparently likes -V 0 and he has had the same
> problems with mpg123, so it is not an isolated issue.
>
> Felix
That sounds strange. What v
> We orignally used V to set the number of bands allowed to be 'over'.
> When
> we changed that, we should have V.
Why? Only to confuse users?
And the idea of V hasn't changed.
btw, what about a "-h x" setting with x in R?
x = -inf : nothing but speed counts
x = 0: best quality we can do now
>> > constant bitrate:
>> > Fraunhofer, lame, Xing, (long pause) bladeenc
>> so blade is so shitty ? doh i have used it for a while, btw at 160, probably
>> better than xing @128 i used before
>
>Comparing blade at 160 with Xing at 128 is like comparing warm pepsi to
>cold coke.
But isen't
Oops, I said that with gogo the VBR setting was higher -> more quality.
This is apparently wrong. The latest version uses a newer lame engine
and thus has the same meaning for that switch as lame.
Sorry!
Felix
--
MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
On Wed, 2 Feb 2000, Robert Hegemann wrote:
> Well, in my opinion -V reflects the following behaviour:
> -V0: allow low amount of noise
> :
> -V4: allow mid amount of noise
> :
> -V9: allow large amount of noise
>
> That's it what VBR does, allocate as much noise
> as allowed to achieve the
On Wed, 2 Feb 2000, Robert Hegemann wrote:
> Greg Maxwell schrieb am Die, 01 Feb 2000:
> > On Tue, 1 Feb 2000, Jeremy Hall wrote:
> >
> > > but then you're in conflict with VBR.
> >
> > VBR should be changed. It makes more sence for big numbers to denote
> > bigger bitrate in VBR.
>
> Well, in
On Tue, 1 Feb 2000, Jeremy Hall wrote:
> I have no problems with adding new options, but changing existing options
> is a bit rough.
Hmm.. I was still in the VBR is beta mindset. This is unfortunate, as the
current situation is not very intutive.
--
MP3 ENCODER mailing list ( http://geek.rcc.se
Thus spake Robert Hegemann ([EMAIL PROTECTED]):
> > By the way: has anyone of you noticed that mpg123 can't play lame
> > encoded mp3s if they contain 320 kbps bitrates? Seems to be mpg123's
> > fault, I'm going to complain to the author about it now ;)
> No, I haven't seen such faults. No proble
> Is the sfBandIndex Table B.8 messed up for MPEG2's
> lower frequencies?
>
> For long blocks the entries B.2.b (22.05kHz) are the
> same as for B.2.a (16kHz)! But the entries for short
> blocks differ.
A comparison between LAME's tables and MPGLIB's (mpg123)
tables show a different value in Tab
> By the way: has anyone of you noticed that mpg123 can't play lame
> encoded mp3s if they contain 320 kbps bitrates? Seems to be mpg123's
> fault, I'm going to complain to the author about it now ;)
No, I haven't seen such faults. No problems with latest mpg123 (0.59r?)
or xmms for me.
> Felix
Thus spake Don Melton ([EMAIL PROTECTED]):
> > No, I didn't use higher bitrates.
> > My rationale is that if you have the space for higher bitrates, you can
> > also use Layer 2. I found recent Xing encoders not as bad as I expected
> > from earlier Xing encoders, but if you use Xing, you use VBR
Thus spake Jeremy Hall ([EMAIL PROTECTED]):
> I disagree. From a functional standpoint, changing an option to cause it
> to do the exact opposite of what it once did is confusing at best, and
> disrupts expected behavior. People upgrading from one release to another
> will find that their "great
Is the sfBandIndex Table B.8 messed up for MPEG2's
lower frequencies?
For long blocks the entries B.2.b (22.05kHz) are the
same as for B.2.a (16kHz)! But the entries for short
blocks differ.
Robert
--
Sent through Global Message Exchange - http://www.gmx.net
--
MP3 ENCODER mailing list ( ht
Thus spake Cavallo de Cavallis ([EMAIL PROTECTED]):
> > I took a few "hard to encode" samples and had the contenders encode them
> > at 96 kbps. The most prominent sample was from a live CD of Herbert
> > Grönemeyer, basically lots of applause.
> Sorry but why did u use 96 ?!?
It is more difficu
Don Melton wrote:
> --qual low equivalent to highq=9
> --qual normal " " " 5
> --qual high " " " 2
The idea to create secondary options may be a good way to avoid confusion.
LAME is starting to take off as a quality encoder so the us
31 matches
Mail list logo
