drbeachboy
Dec 28 2007, 17:33
QUOTE(halb27 @ Dec 28 2007, 16:56)
It's personal judgement how to feel about a problem.
Anyway it's a real problem that hopefully will be repaired.
That is precisely the point; I didn't hear the problem, so I thought the original post was overly exaggerated. If there is a problem, I agree that it needs to be addressed, but it also sounded like a LAME trashing. Also, as kkumul pointed out, his rationale for not using VBR due to the lack of two-pass encoding was totally incorrect. The post just sounded like more of a rant than an actual issue. I stand corrected on the echo problem.
Martel
Dec 28 2007, 17:59
QUOTE(drbeachboy @ Dec 28 2007, 15:33)
QUOTE(halb27 @ Dec 28 2007, 16:56)
It's personal judgement how to feel about a problem.
Anyway it's a real problem that hopefully will be repaired.
That is precisely the point; I didn't hear the problem, so I thought the original post was overly exaggerated. If there is a problem, I agree that it needs to be addressed, but it also sounded like a LAME trashing. Also, as kkumul pointed out, his rationale for not using VBR due to the lack of two-pass encoding was totally incorrect. The post just sounded like more of a rant than an actual issue. I stand corrected on the echo problem.
I don't have any reason to put shame on LAME, I might have even exaggerated the problem as well, sorry. Perhaps it's all those years of not using MP3 and then hearing new version being much worse than the four-years-old one, than the standard I was used to. It kind of agitated me to see such "development" and as I barely remember, similar problems were with 3.97 early version some three years ago... Nobody listened to me at that time so I gave up. Now I returned after three years to try again, fortunately I see someone else noticed the problem as well this time... Perhaps, there is hope left after all.
I hope my contribution helps to open your eyes and get together. I have no reason to cause flame of any sort... I'm far too old for that stuff.
Vitecs
Dec 29 2007, 02:37
What people mean by telling that development goes to VBR? AFAIU it's about "polishing" -Vx modes. So, if even no development in CBR how it can happen we've got such degradation? Is it related to introduced new psy model? 3.98 still have 128 bps bandwith for encode as well as 3.96 had...
P.S. I hear the difference in provided samples, and amount of added sounds is very distracting. FYI: -V4 is transparent to me.
Are there any source tarballs for 3.98b6? Or you can get it only through cvs?
QUOTE(halb27 @ Dec 28 2007, 20:57)
Yes, that's the link I meant. And like Med0 and AlexB I can confirm your finding: the -b128 encoding is real bad, kind of a long-lasting additional echo.
I can easily hear it as well (in both 3.96.1 and 3.98b6) but I tried to identify it on the left and right channel independently and here it might start to become interesting.
The thing is that the guitar is on the left side close to the micro and it gives a clear sound in the left channel for the WAV sample. Everything ok. 3.98b6 and 3.96.1 both really sound as if there is a permanent echo on the left side.
In the right channel on the other hand it sounds as if there is some interference and a permanent echo in the WAV-file (maybe a wall reflecting the sound waves). This echo can also be found in the two MP3 files. I cannot identify a difference between the WAV file and the two MP3 files for the right channel. The echoes in the WAV-file (right channel) sounded to me very similar to the permanent echoes present in the MP3 files on the left channel.
So I assumed that it might be not a standard pre-echo in the left channel (sounds a bit different from pre-echo as I understand it) but a channel coupling interference between the left and the right channel due to the joint stereo mode of the MP3 files.
So I used lame3.98b6 and encoded the test file with -h -b 128 -md, therefore producing a dual-channel file.
But apparently I was wrong and the left channel sounded as distorted as before - so (probably) no channel coupling issue.
halb27
Dec 29 2007, 14:20
I also thought of a joint stereo problem and tried forced stereo (-m s), but without success.
Quite interesting however that 3.96.1 is affected too. Didn't sound like that so far.
soultrain
Dec 29 2007, 14:24
Hm i always thought i had a good hearing (i did a lot of testing before with different encoder settings/versions). But it seems i also dont have the golden ears because after listening 10 times to each sample, i just cant hear the difference between them on my pc / pcspeakers.
halb27
Dec 29 2007, 14:28
If you like to try it again: it's already within the first 3 seconds, and it's an added echo (I think 'echo' describes it best, but don't think of pre-echo problems).
Oh, and usually problems are easier to hear with headphones/earphones than with speakers.
soultrain
Dec 29 2007, 14:45
Indeed, thanks if you know were and what to listen you can hear it very clearly. It remind me of the sound the plastic tubes made in the 70's. You had to swing them around your head and then the made a swoozing sound depending on the speed you rotated.
I also did a quick check with my own favorite setting lame --preset fast standard, then it is gone but ofcourse it is bigger 247k instead 183k.
Did another quick test and lowered Vbr from q3 to q4 to q5 (q5 is as big as the original 128k cbr sample mp3). And i could not hear the "swooz" anymore.
btw i have a question of my own. I noticed in cmd line mode that lame uses 2 different signs for the bars.
112 [ 82] %%%%%%%%%%%%%%%%%%%*****************
If i remember correct it was always 1 sign (*). Whats the meaning / difference of the "%" and the "*"?
QUOTE(soultrain @ Dec 29 2007, 22:45)
Did another quick test and lowered Vbr from q3 to q4 to q5 (q5 is as big as the original 128k cbr sample mp3). And i could not hear the "swooz" anymore.
What I found most interesting was that the encoded file sounds fine if you use vbr, even if you only use one frame size (i.e. 128kbps).
halb27
Dec 29 2007, 15:36
Yes, and to me it's an indication that CBR/ABR mode was not as much in the devs' focus as was VBR.
I can confirm Ojay's finding that 3.96.1 is affected too. But to my ears it is so at a considerably minor degree.
I went further back in time and tried 3.93.1, 3.92, 3.91, 3.90.3, and it takes a lot of concentration now to abx the problem. If the problem wasn't known in advance I can't imagine it would be found within practical listening.
In contrary to Lame 3.96.1+ when using -b 128 with 3.93.1- the psy model gpsycho is used.
Using nspsytune with these older versions (as is done with 3.96.1+) by means of '--alt-preset cbr 128' brings back the problem to these old versions as well.
So it is a nspsytune problem which however is overcome when using VBR.
soultrain
Dec 29 2007, 16:25
If its a cbr only problem, then it would be also intresting to know at which bitrate it dissapears, if it dissapears.
QUOTE(Martel @ Dec 28 2007, 17:12)
No offense meant, but I sincerely hope that you or people like you don't help develop LAME.
If you don't know what to look for - the 398 version adds audible (pre?)echo to both audio channels (before vocals come in). 3961 adds only almost inaudible one.
I use Sennheiser HD 490 headphones and an integrated Realtek HD audio sound card (Asus P5K). And I can hear the mess despite the mediocre setup I have.
If noone else can confirm the fuzz, then there's no hope for you guys. LOL
I think I'm going to back up my 3961 version of Lame pretty good.
OK OK I must admit that at first I didn't listen to carefully enough and I listened to it with crappy laptop speakers. Now with proper headphones I can definitely hear it...
QUOTE(soultrain @ Dec 29 2007, 23:45)
btw i have a question of my own. I noticed in cmd line mode that lame uses 2 different signs for the bars.
112 [ 82] %%%%%%%%%%%%%%%%%%%*****************
If i remember correct it was always 1 sign (*). Whats the meaning / difference of the "%" and the "*"?
I think its about stereo-mono data distrubution in join mode.
As a praticle matter, if you are concerned about size, VBR is clearly the way to go and has no problems. If size doesn't matter, use CBR at a high bitrate which has no problems. Since VBR is superior to CBR at low bitrates, this is like trying to fit a square peg into a round hole!
Alex B
Dec 30 2007, 11:04
QUOTE(soultrain @ Dec 30 2007, 00:25)
If its a cbr only problem, then it would be also intresting to know at which bitrate it dissapears, if it dissapears.
The problem is still obvious at 160kbps, but it seems to disappear at 192 kbps.
I tried quickly the last 1.5 seconds of my "the first 3 s" clip of the provided sample (I set the additional offset to 1500 ms in the ABC-HR Java settings) using the following encoding settings:
LAME 3.98b6 -b 160 and -b 192
LAME 3.97 -b 160 and -b 192
LAME 3.90.3 -b 160 -h and -b 192 -h
CODE
ABC/HR for Java, Version 0.52b, 30 December 2007
Testname: CBR problem
Tester: Alex B
1R = U:\test\LAME_CBR_problem\3s_clip_3.98b_160.wav
2R = U:\test\LAME_CBR_problem\3s_clip_3.98b_192.wav
3R = U:\test\LAME_CBR_problem\3s_clip_3.97_192.wav
4R = U:\test\LAME_CBR_problem\3s_clip_3.90.3_160.wav
5L = U:\test\LAME_CBR_problem\3s_clip_3.90.3_192.wav
6L = U:\test\LAME_CBR_problem\3s_clip_3.97_160.wav
Ratings on a scale from 1.0 to 5.0
---------------------------------------
General Comments:
---------------------------------------
1R File: U:\test\LAME_CBR_problem\3s_clip_3.98b_160.wav
1R Rating: 3.0
1R Comment: the problem is obvious
---------------------------------------
2R File: U:\test\LAME_CBR_problem\3s_clip_3.98b_192.wav
2R Rating: 4.3
2R Comment: some additional high frequency noise (similar to tape hiss)
---------------------------------------
6L File: U:\test\LAME_CBR_problem\3s_clip_3.97_160.wav
6L Rating: 3.0
6L Comment: the problem is obvious
---------------------------------------
ABX Results:
Original vs U:\test\LAME_CBR_problem\3s_clip_3.90.3_160.wav
6 out of 8, pval = 0.144
Original vs U:\test\LAME_CBR_problem\3s_clip_3.98b_192.wav
7 out of 8, pval = 0.035
Original vs U:\test\LAME_CBR_problem\3s_clip_3.97_192.wav
4 out of 8, pval = 0.636
Original vs U:\test\LAME_CBR_problem\3s_clip_3.90.3_192.wav
2 out of 8, pval = 0.964
---- Detailed ABX results ----
Original vs U:\test\LAME_CBR_problem\3s_clip_3.90.3_160.wav
Playback Range: 00.776 to 01.221
11:35:22 AM p 1/1 pval = 0.5
11:35:36 AM p 2/2 pval = 0.25
11:35:44 AM p 3/3 pval = 0.125
11:35:56 AM p 4/4 pval = 0.062
11:36:00 AM p 5/5 pval = 0.031
11:36:08 AM f 5/6 pval = 0.109
11:36:17 AM f 5/7 pval = 0.226
11:36:30 AM p 6/8 pval = 0.144
Original vs U:\test\LAME_CBR_problem\3s_clip_3.98b_192.wav
Playback Range: 00.744 to 01.496
11:12:21 AM f 0/1 pval = 1.0
11:13:50 AM p 1/2 pval = 0.75
11:14:14 AM p 2/3 pval = 0.5
11:14:40 AM p 3/4 pval = 0.312
11:16:00 AM p 4/5 pval = 0.187
Playback Range: 00.000 to 00.469
11:17:01 AM p 5/6 pval = 0.109
Playback Range: 00.864 to 01.226
11:18:07 AM p 6/7 pval = 0.062
11:19:37 AM p 7/8 pval = 0.035
Original vs U:\test\LAME_CBR_problem\3s_clip_3.97_192.wav
Playback Range: 00.000 to 00.602
11:39:42 AM f 0/1 pval = 1.0
11:40:02 AM p 1/2 pval = 0.75
11:40:18 AM p 2/3 pval = 0.5
11:40:50 AM f 2/4 pval = 0.687
11:41:10 AM p 3/5 pval = 0.5
11:41:43 AM f 3/6 pval = 0.656
11:42:36 AM f 3/7 pval = 0.773
11:42:48 AM p 4/8 pval = 0.636
Original vs U:\test\LAME_CBR_problem\3s_clip_3.90.3_192.wav
Playback Range: 00.720 to 01.202
11:27:53 AM f 0/1 pval = 1.0
11:27:58 AM f 0/2 pval = 1.0
11:28:17 AM p 1/3 pval = 0.875
11:29:21 AM f 1/4 pval = 0.937
11:29:39 AM f 1/5 pval = 0.968
11:30:27 AM f 1/6 pval = 0.984
11:31:20 AM f 1/7 pval = 0.992
11:31:38 AM p 2/8 pval = 0.964
soultrain
Dec 30 2007, 11:15
But then one could ask why would anyone still use cbr, cbr was usefull 10 years ago for mp3 players not supporting vbr.
But today the only use i could think of is for streaming (internetradio) but i believe we have the better abr for that now.
Also when converting al your dvd's without quality loss then 320cbr could be usefull. But thats all i can think of.
Maybe its not a bad thing that they focus only on vbr, dont know about abr. cbr seems to me something oldskool. vbr seems to me the only way to go.
Alex B
Dec 30 2007, 11:48
This is not about CBR limitations in general. This is about something that worked fine before the v. 3.97 and for some reason doesn' t work anymore. I hope the LAME developers can find the reason for this obvious regression and fix it. Maybe it is just a mishap somewhere in the current code.
soultrain
Dec 30 2007, 12:01
Ah ok i didnt knew that
Alex B
Dec 30 2007, 13:38
I tried to find other samples which would have similar characteristics and possibly trigger the same problem. I have tested a few, but not found anything similar yet.
While doing this I noticed that Martel's reference sample has a lowpass filter applied at about 16 kHz. I am not trying to guess if the sample is from a lossy source or if one of the official versions of the track really has this kind of filter applied.
I have Bee-Gees' "Tales From The Brothers Gibb" compilation from the year 1990 in my archive. It has a version of the same track. It is quieter, less compressed and doesn't have a distinctive low pass frequency.
I uploaded a sample of the same passage here:
http://www.hydrogenaudio.org/forums/index....showtopic=60113 In any case, the same problem exists when files are encoded from my version of the sample so the problem is not caused by the possibly transcoded sample.
halb27
Dec 30 2007, 15:44
Sorry I ran upon another
problem for Lame I could abx 10/10 using Lame (3.98b6) -V0.
is the latest cvs code change affect in encoding speed?
im just
compiled one from cvs with mingw gcc4.21sjlj, encoding speed seems abit faster than rarewares build.
and i noticed some console info is mssing on new build,
eg:
quantization: xr^3/4
...
using psychoacoustic model: 1
psychoacoustic model: NSPsytune
is there something wrong with gcc or compiling problem?
P.S. im still pretty new to ha.org and coding world
Martel
Dec 31 2007, 04:40
QUOTE(Alex B @ Dec 30 2007, 11:38)
I tried to find other samples which would have similar characteristics and possibly trigger the same problem. I have tested a few, but not found anything similar yet.
While doing this I noticed that Martel's reference sample has a lowpass filter applied at about 16 kHz. I am not trying to guess if the sample is from a lossy source or if one of the official versions of the track really has this kind of filter applied.
I have Bee-Gees' "Tales From The Brothers Gibb" compilation from the year 1990 in my archive. It has a version of the same track. It is quieter, less compressed and doesn't have a distinctive low pass frequency.
I uploaded a sample of the same passage here:
http://www.hydrogenaudio.org/forums/index....showtopic=60113 In any case, the same problem exists when files are encoded from my version of the sample so the problem is not caused by the possibly transcoded sample.
The sample is from "Bee Gees - The Greatest Hits vol. 1". I think it's just the "modern" remastering...
Bourne
Jan 11 2008, 11:05
@halb27
does the problem you spotted in LAME persists in 320kbps CBR?
halb27
Jan 11 2008, 15:19
QUOTE(Bourne @ Jan 11 2008, 19:05)
@halb27
does the problem you spotted in LAME persists in 320kbps CBR?
I don't know but I will try it.
But it will take some time as my system is down (I'm just using my wife's notebook).
TimeTripper
Jan 12 2008, 03:44
Forgive me for being a noob, but has anyone brought Martel's problem sample to the attention of Robert or another LAME developer? I can also confirm the 'swoosh' sound in 3.98b6, and its absence in 3.90.1.
shadowking
Jan 12 2008, 04:22
What is all this noise ? Its low volume ringing. 3.97 is the same. I abx easily V5, V4 .. @ V3 I got a bit confused, but after a while I could do it. By V2 its really really close, but I managed 13/16.
Tracks with solo vocal, guitar are 'difficult'. Dibrom said this in old posts.
Alex B
Jan 12 2008, 05:05
QUOTE
Tracks with solo vocal, guitar are 'difficult'. Dibrom said this in old posts.
Yeah, but the LAME version from "Dibrom's time" doesn't appear to have this particular problem when 128 or 160 kbps CBR is used. (I didn't try VBR because Martel's report was about CBR.)
I hope the regression is caused by some kind of mishap and can be easily fixed without breaking something else.
halb27
Jan 12 2008, 14:38
QUOTE(Bourne @ Jan 11 2008, 19:05)
@halb27
does the problem you spotted in LAME persists in 320kbps CBR?
I've tried to build an uptodate system based on my old one, but didn't succeed. Looks like the mainboard or memory (or their cooperation) isn't alright. So I reinstalled my old components.
I just relistened to the problem again and - shame on me - can't abx it at all using -V0. Maybe I'm still too upset with my system trouble. I also tried -b320 and got at 5/6 which in the end turned out to be 6/10 - the very kind of result I formerly often got with french woman singers: too good to be ignored and too bad to take it as a proper abx result. Trying -V0 again for a final check I had no chance to abx it.
Despite my poor results I think it's enough to conclude that -b320 doesn't solve the problem.
buktore
Jan 12 2008, 15:25
QUOTE
@halb27
does the problem you spotted in LAME persists in 320kbps CBR?
I have the same experience as halb27. fail at 320kbps.
But even at q-0 the problem is very slight and not annoying. (for me at least) It may actually transparent to your ear.
Why there is no sources for 3.98 betas on
SourceForget.net: LAME Dowload page?
There was betas before 3.97 version. Or its not good enought for it?
QUOTE(ZinCh @ Jan 13 2008, 01:14)
Why there is no sources for 3.98 betas on
SourceForget.net: LAME Dowload page?
Available via CVS. For example, see here:
http://sourceforge.net/forum/forum.php?thr...mp;forum_id=887
It has been some time since I followed LAME development and reading this thread shows that there are regressions and improvements provided by this new beta version, however I am not into the recent development/testing process.
I have to do some encodes at the V5 range and I was wondering if 3.98b6 is safe to use or if I should use the stable 3.97 version instead. I intend to use --vbr-new as well to speed up things. Do you see any problems?
thanks
QUOTE(beto @ Mar 4 2008, 23:08)
... I have to do some encodes at the V5 range and I was wondering if 3.98b6 is safe to use ....
I'm very happy with 3.98b6 but my experience is with -V3+, and with this I prefer 3.98 over 3.97. I guess the advantageous behavior is valid for -V5 too, but can't really tell about it.
LoFiYo
Mar 23 2008, 20:11
I tested a 30 second sample using 3.98b6 (Mar 12, 2008) vs 3.97 both with -V 6 --vbr-new, and on this sample, I noticed regression from 3.97. I'm sorry that I haven't done any listening test on Lame lately, and this finding may be too late to be any help for the final 3.98 release, but it might amount to something for your future development. I will try to find more regression later if I can.
Considering that very few people (or none that I remember) have reported regression issues with 3.98b6 at low bitrate, this may well be an exception, but I don't think this sample is a killer sample or anything. I will upload it to the Upload section in a few minutes (first 30 seconds of Giant Steps by Coltrane).
ABC/HR Version 0.9b, 30 August 2002
Testname: 3.97 -V 6 --vbr-new vs 3.98b6 -V 6
1R = C:\My Test Samples\gsteps\398.mp3.wav
2L = C:\My Test Samples\gsteps\397.mp3.wav
---------------------------------------
General Comments:
sample #2 was much harder to ABX.
---------------------------------------
1R File: C:\My Test Samples\gsteps\398.mp3.wav
1R Rating: 1.0
1R Comment: Distortion is severe throughout the sample.
---------------------------------------
2L File: C:\My Test Samples\gsteps\397.mp3.wav
2L Rating: 2.0
2L Comment: Distortion is not nearly as severe as #1.
---------------------------------------
ABX Results:
Original vs C:\My Test Samples\gsteps\398.mp3.wav
8 out of 8, pval = 0.004
Original vs C:\My Test Samples\gsteps\397.mp3.wav
7 out of 8, pval = 0.035
C:\My Test Samples\gsteps\398.mp3.wav vs C:\My Test Samples\gsteps\397.mp3.wav
8 out of 8, pval = 0.004
Just an observation from your results:
QUOTE(LoFiYo @ Mar 24 2008, 03:11)
sample #2 was much harder to ABX.
1R Rating: 1.0
2L Rating: 2.0
2L Comment: Distortion is not nearly as severe as #1.
ABX Results:
Original vs C:\My Test Samples\gsteps\397.mp3.wav
7 out of 8, pval = 0.035
C:\My Test Samples\gsteps\398.mp3.wav vs C:\My Test Samples\gsteps\397.mp3.wav
8 out of 8, pval = 0.004
I would have no problems ABX ing something that I rate as "Annoying".
LoFiYo
Mar 24 2008, 06:14
QUOTE
' date='Mar 24 2008, 05:32' post='554570']
Just an observation from your results:
QUOTE(LoFiYo @ Mar 24 2008, 03:11)
sample #2 was much harder to ABX.
1R Rating: 1.0
2L Rating: 2.0
2L Comment: Distortion is not nearly as severe as #1.
ABX Results:
Original vs C:\My Test Samples\gsteps\397.mp3.wav
7 out of 8, pval = 0.035
C:\My Test Samples\gsteps\398.mp3.wav vs C:\My Test Samples\gsteps\397.mp3.wav
8 out of 8, pval = 0.004
I would have no problems ABX ing something that I rate as "Annoying".
That means that my ears aren't that good.
Spikey
Mar 24 2008, 13:44
If people are complaining about 3.98b6, why aren't people using the previous beta that apparently didn't have those issues?
Is it because Rarewares doesn't have it anymore?
- Spike
QUOTE(LoFiYo @ Mar 24 2008, 13:14)
That means that my ears aren't that good.
It is not about ears. It is about terminology. If it annoys you, you're disturbed while listening to it. i.e. you wouldn't listen to it for a prolongued period of time.
I am sure you meant to rate it between 4 and 5, which stands for "Perceptible, but not annoying". I.e. You could happen to hear it, (in your case you had to put efforts on it), so in a casual listening you wouldn't mind/notice it, and as such, not annoy you.
I stress this point, because else, the listening tests that we run sometimes here, wouldn't have much sense. If a thing is either 5 (Not perceptible) or 2 (Annyoing), The scale is converted to something like is either white or black.
Don't take this as personal, but rather as a thing to think about when doing abc-hr tests, alright?
LoFiYo
Mar 24 2008, 15:25
The file I promised has been uploaded
here.
halb27
Mar 25 2008, 07:32
I can confirm the problem. 3.97 is better here with -V6 for me too .
gfxnow
Mar 31 2008, 14:37
is there a release schedule for the final version of 3.98?
Just noticed Updated Beta 6 :
"
LAME 32bits version 3.98 (beta 6, Mar 12 2008) (http://www.mp3dev.org/)"
Sources -
http://sourceforge.net/project/showfiles.p...;package_id=309Binaries -
http://rarewares.org/mp3-lame-bundle.php"
lame 3.98 beta 6 (small fix) Notes(2008-03-12 13:47)"
CVS -
http://lame.cvs.sourceforge.net/lame/lame/...me/?sortby=date// @ devs : check
my ticket please
QUOTE(ZinCh @ Apr 4 2008, 10:12)
Just noticed Updated Beta 6 :
"[b]LAME 32bits version 3.98 (beta 6, Mar 12 2008) ...
Wouldn't it be better to have a new beta version instead of multiple versions of the same beta? This causes confusion when talking about found bugs.
Anyone know what's actually changed in the new beta 6?
- Spike
QUOTE(Spikey @ Apr 5 2008, 19:00)
Anyone know what's actually changed in the new beta 6?
- Spike
http://lame.cvs.sourceforge.net/*checkout*...ml/history.html
QUOTE(bilbo @ Apr 6 2008, 07:54)
QUOTE(Spikey @ Apr 5 2008, 19:00)
Anyone know what's actually changed in the new beta 6?
- Spike
http://lame.cvs.sourceforge.net/*checkout*...ml/history.htmlThe changelog on the url mentioned above still says, "LAME 3.98 beta 6 December 16 2007". Has it been updated to incorporate the changes that went into the subsequent re-released beta6?
--Vinu.
QUOTE(vinu @ Apr 6 2008, 15:06)
The changelog on the url mentioned above still says, "LAME 3.98 beta 6 December 16 2007". Has it been updated to incorporate the changes that went into the subsequent re-released beta6?
--Vinu.
You can read
http://lame.cvs.sourceforge.net/lame/lame/...me/?sortby=date and other pages.
CODE
psymodel.c 1.178 9 hours robert some simpler spreading function for VBR NEW
set_get.c 1.87 9 hours robert some simpler spreading function for VBR NEW
version.h 1.114 9 hours robert some simpler spreading function for VBR NEW
presets.c 1.65 9 hours robert some simpler spreading function for VBR NEW
lame_global_flags.h 1.44 9 hours robert some simpler spreading function for VBR NEW
id3tag.c 1.52 19 hours robert changing some links from "www.mp3dev.org/mp3" to "www.mp3dev.org" and from "www....
Interesting: current CVS compile says it's beta
7:
CODE
LAME 32bits version 3.98 (beta 7, Apr 6 2008) (http://www.mp3dev.org/)
Edit: formatting
GeSomeone
Apr 6 2008, 07:32
Time for a
new thread (click) then
Let's not get into the situation we had with b6 that the release number had changed but the beta wasn't ready for release yet. It's official now
QUOTE(Spikey @ Apr 6 2008, 00:00)
Anyone know what's actually changed in the new beta 6?
could it be one of fixes in the remarks on rarewares?
QUOTE
(Includes the decoding fix for mp3 files and the fix for decoding through stdout. Both now included in CVS. Also now includes Nyaochi's Album Art Id3 Patch, also in the CVS.)
I'll get some beta 7 compiles up in a couple of hours, or so. (I was away over night and only just returned home.
)
This is a "lo-fi" version of our main content. To view the full version with more information, formatting and images, please
click here.