Thus spake Mark Taylor ([EMAIL PROTECTED]):
> If no problems show up with 3.80, then in a few weeks I think
> we should make another official release, and finally drop all
> the dist10 patching stuff!
VBR is 5-10% slower than with 3.70. How comes?
Is it very difficult to integrate Takehiro's VBR
Sorry to bother you with this, but where is the Lame CVS server?
Felix
--
MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
> Any ideas?
Sorry, that was a mistake in the pipe, lame was innocent.
Felix
--
MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
lame 3.69 and 3.70 produce skippy sound when used over RTP.
I found that this is not the fault of my RTP code but even the file that
mp3rtp writes (not just the data it sends over RTP) contain skips. About
half a second sound, then half a second pause. Sounds really crappy.
Since the Wave file d
Thus spake Jeremy Hall ([EMAIL PROTECTED]):
> then the current lame seg faults. I have not figured out how to gather
> more info because it is in a pipe, like this.
Are you using an egcs snapshot?
Use gcc-2.95.2 instead, it is much more stable. I found the egcs
snapshots from the last months to
> it prints a warning that one of its packets was missing. In addition to
> the packet transmitted is a packet number. When they are out of sequence
> or missing, the utility whines about it.
I am currently writing a receiver than substitutes the packet with the
closest sequence number instead.
Thus spake Ivo van Heel ([EMAIL PROTECTED]):
> > Personally, I use LAME 160 stereo for all my encodes, fast and sounds great
> > to me.
> Is 160 really high enough to warrant not using joint stereo anymore? I always
> encode with LAME 160 joint stereo, but maybe I should convert :)
> I agree in t
Thus spake Rolf Hanich ([EMAIL PROTECTED]):
> Maybe you should have a look on the new Fraunhofer plugin, as used in Nero.
Sorry, but I cannot test all incarnations of Fraunhofer plugins in the
world. The MusicMatch software is quite recent so I expected the
plugin to be to current version.
> It
> Your rtp thing probably encodes one frame per packet. My little utility
> grabs 1k of data and transmits it.
How does your utility expect the receiver to recover from packet loss?
Felix
PS: I'm out of town until Feb 10 and won't have email in the mean time.
--
MP3 ENCODER mailing list ( http
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
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
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/ )
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
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
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
Thus spake Don Melton ([EMAIL PROTECTED]):
> > constant bitrate:
> > Fraunhofer, lame, Xing, (long pause) bladeenc
> Did you do any testing at higher bit rates as well? I'd be curious what
> the results would be at 160 or 192. (My wife, who has hearing a tall
> dog would envy, can pick out
Thus spake Don Melton ([EMAIL PROTECTED]):
> > PS: This is my first email to this list, so I should also mention that I
> > submitted the RTP patch to lame (in case anyone wants to ask me
> > anything about it).
> Wow, I should have been so nice with my first post last night. :-)
> Felix, everyo
Thus spake Greg Maxwell ([EMAIL PROTECTED]):
> > But even more important than the encoder test is another article (in the
> > same issue) they did after I suggested to do some double blind tests of
> > MP3 against audio CDs with musicians and so-called audiophiles and none
> > of them was able to
Thus spake Robert Hegemann ([EMAIL PROTECTED]):
> By the way:
> LAME gets press coverage in Germany's respected c't computer magazine,
> which will appear on newsstands tomorrow, monday.
> I've heard, they've tested LAME against Xing, Fraunhofer and some other
> encoders at constant and variable
21 matches
Mail list logo
