Help - Search - Members - Calendar
Full Version: Lame 3.98b4
Hydrogenaudio Forums > Lossy Audio Compression > MP3 > MP3 - General
halb27
Sorry I don't have the time for an adequate test, but I'm leaving for holidays tomorrow.
I just went quickly through my usual samples using -V2, and in an overall view I'd say there isn't a big change compared to b3. Some samples are even bit-identical.
Exception is eig. To my ears eig behavior is further improved, and if there weren't this little spot at ~ sec. 3 the result to me was pretty perfect. Very good result for such an mp3 hard sample!
Wombat
QUOTE(halb27 @ Jun 25 2007, 21:43) *

Sorry I don't have the time for an adequate test, but I'm leaving for holidays tomorrow.
I just went quickly through my usual samples using -V2, and in an overall view I'd say there isn't a big change compared to b3. Some samples are even bit-identical.
Exception is eig. To my ears eig behavior is further improved, and if there weren't this little spot at ~ sec. 3 the result to me was pretty perfect. Very good result for such an mp3 hard sample!

Indeed smile.gif
eig got better. You can still hear smearing, especially on these clicks at second 2-3 but it is far from being an annoying artefact at -V2. 3.97 is horrible in comparison.
At least V2 gets really solid with these newer builds even if it needs more bits sometimes.
Since other kind of samples donīt change in bitrate i hope lame is getting better in handling such demanding parts by really detecting it.

Big compliment to the devs!
haregoo
QUOTE(halb27 @ Jun 26 2007, 04:43) *

Sorry I don't have the time for an adequate test, but I'm leaving for holidays tomorrow.
I just went quickly through my usual samples using -V2, and in an overall view I'd say there isn't a big change compared to b3. Some samples are even bit-identical.
Exception is eig. To my ears eig behavior is further improved, and if there weren't this little spot at ~ sec. 3 the result to me was pretty perfect. Very good result for such an mp3 hard sample!

CODE
Comparing:
"E:\Sample02 eig b4 V2.mp3"
"E:\Sample02 eig b3 V2.mp3"
No differences in decoded data found.

What did you find from these?

#Try ABC/HR for direct comparison next time. You always suffer from placebo effect unless you use ABC/HR.
Wombat
QUOTE(haregoo @ Jun 25 2007, 22:22) *

QUOTE(halb27 @ Jun 26 2007, 04:43) *

Sorry I don't have the time for an adequate test, but I'm leaving for holidays tomorrow.
I just went quickly through my usual samples using -V2, and in an overall view I'd say there isn't a big change compared to b3. Some samples are even bit-identical.
Exception is eig. To my ears eig behavior is further improved, and if there weren't this little spot at ~ sec. 3 the result to me was pretty perfect. Very good result for such an mp3 hard sample!

CODE
Comparing:
"E:\Sample02 eig b4 V2.mp3"
"E:\Sample02 eig b3 V2.mp3"
No differences in decoded data found.

What did you find from these?

#Try ABC/HR for direct comparison next time. You always suffer from placebo effect unless you use ABC/HR.

lol! my 3.98b3 is 420.934k and b4 is 421.040k
and the big click at second 2-3 with b3 is not worth an abx.
haregoo
QUOTE(Wombat @ Jun 26 2007, 05:30) *

lol! my 3.98b3 is 420.934k and b4 is 421.040k
and the big click at second 2-3 with b3 is not worth an abx.

Maybe you have the first compile released on 2007-05-22. AFAIK there were 3 version of beta3 on Rareware: 2007-05-22, 2007-05-25 and 2007-06-06. The last two compiles have completely identical output with beta4 and the first one could have a bug. history.html metioned every improvement version over verson and there are no improvement since beta2 regarding quality.

The difference you two guys heard are not improvement of beta4.
Wombat
QUOTE(haregoo @ Jun 25 2007, 23:26) *

QUOTE(Wombat @ Jun 26 2007, 05:30) *

lol! my 3.98b3 is 420.934k and b4 is 421.040k
and the big click at second 2-3 with b3 is not worth an abx.

Maybe you have the first compile released on 2007-05-22. AFAIK there were 3 version of beta3 on Rareware: 2007-05-22, 2007-05-25 and 2007-06-06. The last two compiles have completely identical output with beta4 and the first one could have a bug. history.html metioned every improvement version over verson and there are no improvement since beta2 regarding quality.

The difference you two guys heard are not improvement of beta4.

My b3 is from 22-05 and is different to b4. b4 to b2 is much different again and much improved handling this eig sample, even if there is no entry in the history.
Did you try to listen and qualify?

Edit: before more confusion arises. My b2 is from 16-05
haregoo
QUOTE(Wombat @ Jun 26 2007, 06:37) *

My b3 is from 22-05 and is different to b4. b4 to b2 is much different again and much improved handling this eig sample, even if there is no entry in the history.
Did you try to listen and qualify?

Edit: before more confusion arises. My b2 is from 16-05

I don't have beta2 and you don't have b3 (2007-05-25 and 2007-06-06). That makes us confused.

All the thing I can tell is the fix on eig was included in beta3 of 2007-05-25.
halb27
My b3 is from 2007-05-22 as well.
While I can understand robert (guess he doesn't want an inflation of version numbers) it's not a very good idea IMO to have different encoder versions under the same name.
xmixahlx
the other beta3's on rarewares included patches not affecting quality, and were accepted into cvs beta4(pre).

and john33 manages the lame releases on rarewares, not robert(o).


later
jlib
I very much appreciate having access to a compiled binary but I find the rolling binaries a little annoying. Not their existence but calling them all the same beta when they have post-release patches. I'm not sure what the binary naming convention should be but minimally it should have a "beta x+" or something to indicate it is not compiled from the officially released source code.
john33
QUOTE(xmixahlx @ Jun 26 2007, 00:17) *

the other beta3's on rarewares included patches not affecting quality, and were accepted into cvs beta4(pre).

and john33 manages the lame releases on rarewares, not robert(o).


later

Actually, I think he may have been refering to the lame-dev Robert (Hegemann), known as 'Robert' on here. wink.gif
xmixahlx
mmm yeah i dunno (not psychic)...

smile.gif
Bodhi
I often got files at more than 230 Kbps using V2. How comes?
LaserSokrates
LAME assumes that more bitrate is needed to achieve the quality defined by V2.
Bodhi
QUOTE(LaserSokrates @ Jun 27 2007, 10:25) *

LAME assumes that more bitrate is needed to achieve the quality defined by V2.

I know but it didn't happen with previous version! It was more about 190Kbps.
I'm glad I didn't choose V0 laugh.gif
Shure
Good
/mnt
QUOTE(Bodhi @ Jun 27 2007, 08:36) *

I often got files at more than 230 Kbps using V2. How comes?

LAME 3.98 is forced to use stricted ISO mode now, thanks to the buggy FhG mp3 decoder that ships with Windows and this also reduces the bits that is stored on the bit reservoir so LAME will need to use more high bit rate frames now to get more bits since the reservoir is smaller then on 3.97.

I failed to ABX the trumpet killer sample at -V 2 which is very easy to ABX on 3.97 at -V 2 --vbr-new, seems like they have made some major improvements on the new VBR mode.

The new tagging features are really nice you can now add custom genres and album art now without using a tag editor.

Does anyone know what the tagging --tv switch does?
Raiden
QUOTE(/mnt @ Jul 3 2007, 21:52) *

QUOTE(Bodhi @ Jun 27 2007, 08:36) *

I often got files at more than 230 Kbps using V2. How comes?

LAME 3.98 is forced to use stricted ISO mode now, thanks to the buggy FhG mp3 decoder that ships with Windows and this also reduces the bits that is stored on the bit reservoir so LAME will need to use more high bit rate frames now to get more bits since the reservoir is smaller then on 3.97.

I'm pretty sure that's not the reason as the size of the bit reservoir gets only problematic for some decoders if the total bitrate of a frame exceeds 320 kbps, which isn't a big problem in the V2 range.

More probably it's the recent tuning that was more about quality than quantity, which is in principle a good thing. But IMO the average bitrate range should be lowered at least to old 3.90.3 APS range, because people don't expect so high bitrates with V2.
xmixahlx
QUOTE(/mnt @ Jul 3 2007, 12:55) *

Does anyone know what the tagging --tv switch does?


from the lame SF patch tracker:
http://sourceforge.net/tracker/index.php?f...amp;atid=300290

QUOTE

This patch enhances LAME frontend to write user-defined ID3v2.3 frames,
introducing a new option --tv:
--tv <ID=VALUE>
An argument for the --tv option consists of ID and VALUE separated by
a '=' character:
ID: four letters representing ID3v2.3 frame ID
VALUE: text value for the frame
If --tv options are specified multiple times, this patch write all of
them in the appearance order as the command-line arguments.

Some existing options for ID3 tag can be specified by --tv option
as follows.
--tt <value>, --tv TIT2=value
--ta <value>, --tv TPE1=value
--tl <value>, --tv TALB=value
--ty <value>, --tv TYER=value
--tn <value>, --tv TRCK=value
--tg <value>, --tv TCON=value
(although some are not exactly same)

My initial motivation was just to add TCMP frame (flag indicating a
compilation album; typically generated by iTunes), but generalized to
--tv option, and realized with the command-line "--tv TCMP=1".



later
/mnt
QUOTE(xmixahlx @ Jul 6 2007, 01:08) *

QUOTE(/mnt @ Jul 3 2007, 12:55) *

Does anyone know what the tagging --tv switch does?


from the lame SF patch tracker:
http://sourceforge.net/tracker/index.php?f...amp;atid=300290

QUOTE

This patch enhances LAME frontend to write user-defined ID3v2.3 frames,
introducing a new option --tv:
--tv <ID=VALUE>
An argument for the --tv option consists of ID and VALUE separated by
a '=' character:
ID: four letters representing ID3v2.3 frame ID
VALUE: text value for the frame
If --tv options are specified multiple times, this patch write all of
them in the appearance order as the command-line arguments.

Some existing options for ID3 tag can be specified by --tv option
as follows.
--tt <value>, --tv TIT2=value
--ta <value>, --tv TPE1=value
--tl <value>, --tv TALB=value
--ty <value>, --tv TYER=value
--tn <value>, --tv TRCK=value
--tg <value>, --tv TCON=value
(although some are not exactly same)

My initial motivation was just to add TCMP frame (flag indicating a
compilation album; typically generated by iTunes), but generalized to
--tv option, and realized with the command-line "--tv TCMP=1".



later


Thanks for the information on that switch, i had a quick play with it and it is very usefull for Various Artist albums and custom tags and easy to use when find a list a id3 frames.

I used the --tv and ripped a VA soundtrack on EAC with this command:

-V 2 --add-id3v2 --pad-id3v2 --ignore-tag-errors --ta "%a" --tt "%t" --tg "%m" --tl "%g" --ty "%y" --tn "%n/%x" --tv TCMP=1 --tv TPE2="Various Artists" %s %d

This tags mp3s with the BAND tag and iTunes compile tag. WMP sorteted the soundtrack as a VA album and iTunes sorted it out as a compilation out of the bog without using a different id3 tagger.

But I don't know if foobar2000 uses a id frame for ALBUM ARTIST though.
shadowking
QUOTE(Wombat @ Jun 26 2007, 06:04) *

eig got better. You can still hear smearing, especially on these clicks at second 2-3 but it is far from being an annoying artefact at -V2. 3.97 is horrible in comparison.
At least V2 gets really solid with these newer builds even if it needs more bits sometimes.
Since other kind of samples donīt change in bitrate i hope lame is getting better in handling such demanding parts by really detecting it.

Big compliment to the devs!


I played around with this EIG and its like Florida seq sample from JohnV. 3.97 -V2 is heard outside abx at 2-3 secs. A bigger problem is @ 3~4 secs that is almost masked by the keys. -V0 and high. bitrate ABR not very noticeable outside abx. Anyway, 3.98 -V2 is better, ABR same as 3.97.. Still abxing 3.98 @ 320k was possible without much effort and I was under the impression that 3.98 was worse than 3.97 .. So going above -V2 [ABR 250~280k] has some uses, but going to 320k is useless as there are cases like these that are easily abxable @320k.

What can be done really about this? According to Dibrom and JohnV : Nothing without some major overhaul to the format.

I found something much worse than EIG, easily heard @320k and vorbis also suffers preecho upto Q7. @ Q8 the bitrate was 313k and I failed to abx but had the impression it wasn't 100%. Even at Q5 it sounds better than mp3 @ 320k.

Fortunately, it is 100 % artificial - not on a music CD.

link:

http://www.hydrogenaudio.org/forums/index....showtopic=56186
Jojo
so -V2 now uses -q0 as default?
dannyb37
Does anyone here happen to know when beta 5 is going to be released?
Skylined ;)~
QUOTE(dannyb37 @ Aug 5 2007, 10:59) *

Does anyone here happen to know when beta 5 is going to be released?


I guess when it's ready...

There should be something posted by the LAME devs "when it is released"

You should also check http://lame.bakerweb.biz/ for automated bleeding edge compiles from the CVS

But then again, I guess more testing should be done on the current BETA! don't you think!

I love beta4 @ V2, but still prefer to use -V0 (I'd rather use -b320 but too big... probably paranoid or something)

PS: I can ABX V2 vs V0 as well as V0 vs b320 on some music thou, not all!
Jojo
QUOTE(dannyb37 @ Aug 5 2007, 07:59) *

Does anyone here happen to know when beta 5 is going to be released?

today or tomorrow, depending on where you live.
john33
QUOTE(Jojo @ Aug 12 2007, 01:33) *

QUOTE(dannyb37 @ Aug 5 2007, 07:59) *

Does anyone here happen to know when beta 5 is going to be released?

today or tomorrow, depending on where you live.

Full set of win32 binaries at Rarewares now. smile.gif
dannyb37
QUOTE(john33 @ Aug 12 2007, 14:31) *

Full set of win32 binaries at Rarewares now. smile.gif


Good news, Thanks! cool.gif
Synthetic Soul
Discussion regarding beta 5 should take place in this thread.
This is a "lo-fi" version of our main content. To view the full version with more information, formatting and images, please click here.
Invision Power Board © 2001-2008 Invision Power Services, Inc.