Skip to main content ↑ ↓

Notice

Please note that most of the software linked on this forum is likely to be safe to use. If you are unsure, feel free to ask in the relevant topics, or send a private message to an administrator or moderator. To help curb the problems of false positives, or in the event that you do find actual malware, you can contribute through the article linked here.
Topic: Lame 3.93.1, testing phase... (one week) (Read 16997 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Lame 3.93.1, testing phase... (one week)

Lame 3.93.1 will be a corrected version of 3.93. (The new changes introduced by Takehiro will be in 3.94).
There is one week of testing period before releasing. You can download the candidate version here:
http://gabriel.mp3-tech.org/lame/lame_test.zip

I would like to hear both negative and positive reports.
If your results are positive, just drop a line, there is no need for a long post.
For negative reports, a more detailled post is needed, with at least a description an a pointer to the sample.

Reports about low bitrates abr presets and medium preset would be nice too.


Thank you for your particpation.

Lame 3.93.1, testing phase... (one week)

Reply #1 –
Ok, nice.

I'll be doing some testing during next week. Hopefully all people who are capable will attend also.
Juha Laaksonheimo

Lame 3.93.1, testing phase... (one week)

Reply #2 –
Howdy,
I am wondering why you don't release the corrected version of LAME as 3.94 and then have 3.95 with Takehiro's changes. I think this would be much better and help people forget 3.93 was released as a "new" version is released. It also helps stop the confusion for some newer people.
Cheers
Scott

Lame 3.93.1, testing phase... (one week)

Reply #3 –
Well, that's how this thread was originally posted, if I remember correctly. My personal preference is for it to be done as 3.93.1 and 3.94, since many (I assume, but I'm one of 'em!) folks have already been experimenting with Takehiro's 3.94 alpha 2, and the introduction of a "new" 3.94 without the changes some of us have come to associate with that release could potentially cause as much confusion, if not more. No one knows how may copies of 3.94 alpha 2 may be floating around; therefore, ir might be best to keep all versions of 3.94 internally compatible.

    - M.

Lame 3.93.1, testing phase... (one week)

Reply #4 –
Howdy,
I can see your point, but i'm sure you could get used to the idea that all of Takehiro changes could go into 3.95 and we have a "fixed 3.93" in 3.94 STABLE.

It would keep the versions smoother. Plus the "versions floating around" are only alphas.

Cheers,
Scott

Lame 3.93.1, testing phase... (one week)

Reply #5 –
Has this fix been added to the cvs yet?

-Jeff

Lame 3.93.1, testing phase... (one week)

Reply #6 –
The fix is commited to cvs into the main branch.

For the version numbers, the decision is not stopped. The current opinion is to use 3.93.1 in order to avoid confision with the already floating-around 3.94 alphas.

Lame 3.93.1, testing phase... (one week)

Reply #7 –
Howdy,
Thats my point. They are only "alphas" not "releases" meaning they can change. I think we need lame 3.94 to contain the fix and correct the wrong....

In what way would it cause confusion? I could only see benifits. Lame 3.92 was released straight after 3.91 to correct the alt-fast standard bug if I remember correctly:)

What the point of having a 3.93.1 release?

Does anyone else think the same?

Scott

Lame 3.93.1, testing phase... (one week)

Reply #8 –
Where can one get the sources of lame 3.93.1? The zip file contains only one exe and in the lame cvs there's no 3.93.1 branch

EDIT: or is it the latest fix to lame/lame/libmp3lame/psymodel.c  (1.114)?

Lame 3.93.1, testing phase... (one week)

Reply #9 –
Yes, it is the latest commit to psymodel.c

Lame 3.93.1, testing phase... (one week)

Reply #10 –
Excuse me Gabriel,
what should i test? 
should i compare a file encoded with lame 3.93.1 and another compiled with lame 3.93?
always --alt-preset standard?

thanks
 

Lame 3.93.1, testing phase... (one week)

Reply #11 –
You should test the binary I provided against previous versions (3.92, 3.90.2,...). No need to test against 3.93, as this binary is made to correct 3.93.

Lame 3.93.1, testing phase... (one week)

Reply #12 –
Quote
Howdy,
Thats my point. They are only "alphas" not "releases" meaning they can change.

There's already enough "room for change" in LAME releases.  It's already confusing enough trying to estimate what will be in release to release.  It has already been said by the LAME devs that Takehiro's code will be in 3.94.  People are expecting this.

Are you going to explain to them that this is not the case each time someone asks what the deal with 3.94 is?  I know that I don't want to, and trust me, there will be plenty of people asking these types of questions.

It makes more sense to release a bug fix as 3.93.1.  Furthermore, I don't think a bug fix is so much indicative of an evolution or big progression in code or features so the revision number should be smaller accordingly.

Edit:  I notice you are a new member on this board... so I don't know how long you've been reading, but if you go back and read some of the discussion about 3.94 and Takehiro's work, it might make more sense to you why 3.93.1 would be the better choice.

Lame 3.93.1, testing phase... (one week)

Reply #13 –
I just gave it another try, and still couldn't hear any difference between 3.92 and lame_test. Presets were --alt-preset cbr 128, standard, insane and also gpsycho at 128k.

I'll be away for work during a couple of days, hope to be back in the weekend.

Hans

Lame 3.93.1, testing phase... (one week)

Reply #14 –
I fully agree with Scott2002. Why giving in 2 identical cases (bugfixes from 3.91 -> 3.92; now: 3.93 -> 3.93.1) two different version-syntaxes? It would be much easier to understand for people, who don't read HA each and every day, which version is the most actual. And over this  an "outsider" for sure didn't hear anything about this 3.94a2-version, and also doesn't know where to download from, 'cause this version is still a little bit "hidden" on this HA-server. And for the others, who know about, it should be easily to explain, why 3.94a2 becomes in the near future a "3.95 stable".

- R.A.F. -
My used codecs and settings:
FLAC V1.1.2 -4 / APE V3.99 Update 4 -high / MPC V1.15v --q 5 / LAME V3.97b2 -V2 --vbr-new / OGG aoTuV V4.51 Lancer -q5

Lame 3.93.1, testing phase... (one week)

Reply #15 –
Does this release correct the problem with "--alt-preset fast" switches?

Lame 3.93.1, testing phase... (one week)

Reply #16 –
-q0 is clearly worse in 3.93.1 cbr/abr than in 3.92 cbr/abr.
It's seriously worse especially with nspsytune.

Example (listen to the hihat hits):
Lame 3.92 --alt-preset cbr 128 -q0
t1_392_AltP-cbr128q0.mp3

Lame 3.93.1 --alt-preset cbr 128 -q0
t1_3931_AltP-cbr128q0.mp3

Gpsycho has less serious problem with this, but there's a quality difference also with gpsycho. vbr -q0 seems to be ok at least with this sample.
Juha Laaksonheimo

Lame 3.93.1, testing phase... (one week)

Reply #17 –
In listening to hihat.wav encoded with various releases of LAME including the 3.93.1 candidate, I've observed some differences that may be of some use. The differences have to do with extent to which the cow bell (I'm from Texas  ) sound at the end of hihat can be heard from the encoded file. The focus has been on --alt-preset 128 (--preset 128) and --alt-preset standard (--preset standard) for releases starting from 3.90.2.

The LAME releases are:
3.90.2  (dibrom)
3.92    (mitiok)
3.93    alphas posted at http://gabriel.mp3-tech.org/lame/
          alpha2 dates identified as: 1May, 1Jul, 31Jul, 15Aug, 31Aug, 1Sep
          alpha3 date identified as: 1Nov
3.93.1  the candidate posted as http://gabriel.mp3-tech.org/lame/lame_test.zip
          and reported in the DOS window as 3.94 alpha1

--alt-preset 128 and --alt-preset standard are used for 3.90.2, 3.92 and the 3.93 alpha's through 15Aug.

--preset 128 and --preset standard are used for the 3.93 alphas after 15Aug and 3.93.1

Hihat.wav was obtained from http://lame.sourceforge.net/download/samples


Findings:
For --alt-preset 128 (--preset 128), only releases 3.90.2 and 3.93.1 reproduced the cow bell sound. All others truncated the sound partially or entirely.

For --alt-preset standard (--preset standard), the cow bell sound was truncated to the same extent for releases 3.92, 31Aug, and 3.93.1. All of the other releases seem to reproduce the cow bell sound.

The determinations were made by listening with modest equipment and comparing against the original .wav file. Nothing fancy.


Summary:
So far as the 3.93.1 candidate, truncation was observed for --preset standard. No truncations were observed with either setting for 3.90.2. Truncations were observed with both settings for 3.92.


Tex

P.S. - 28Nov - Further testing has revealed that the truncations coorelate with the player being used when the original testing was being performed, namely the Windows Media Player 7. With other players that don't have problems with ABR and VBR, no truncation occurs. Looks like the observations above are of no concern as regards the 3.93.1 candidate or the other releases.

Lame 3.93.1, testing phase... (one week)

Reply #18 –
Took some samples from:

http://lame.sourceforge.net/download/samples

I am not done yet, but I noticed something...

I used command line like this:

lame  ftb_samp.wav --alt-preset cbr 128 -q0

lame-394-alpha2: 14 seconds
lame3.90.2-ICL: 1 minute and 37 seconds to finnish!!!
lame3.90.2-MSVC: 1 minute 38 seconds!!
lame test :12 seconds and same result with binary (3.93) from this page 

http://irgendwas.mybinaryblocks.com/~mitiok/

btw. all other compiles allows you to use lower bitrates than other 2 compiles...if you try to run ICL or MSVC compile like this:lame name-of-the-file --alt-preset cbr 64 -q0 no way, the lowest bitrate is 80, when it works.

I quess this does not help a bit...but i will test a litle bit more

Lame 3.93.1, testing phase... (one week)

Reply #19 –
@JohnV: do you think we should put back -q0 to be identical as -q1?

Lame 3.93.1, testing phase... (one week)

Reply #20 –
No, the bitrate problem of --preset fast standard is not corrected in this release.

Lame 3.93.1, testing phase... (one week)

Reply #21 –
Quote
@JohnV: do you think we should put back -q0 to be identical as -q1?

Well, if you listened those samples, you probably agree that you should do something..
If fixing -q0 with cbr/abr is not an option/requires too much work, then you should do something else..
Juha Laaksonheimo

Lame 3.93.1, testing phase... (one week)

Reply #22 –
I think that fixing -q0 is not feasible in a short time. Previously it was the same as -q1, only in november it was changed.
But if I put it back to the q1 state, it will also be for vbr.

Lame 3.93.1, testing phase... (one week)

Reply #23 –
Quote
I think that fixing -q0 is not feasible in a short time. Previously it was the same as -q1, only in november it was changed.
But if I put it back to the q1 state, it will also be for vbr.

Imo it would be wise to go back then.. Some people religiously think that -q0 gives always the best results..
Juha Laaksonheimo

Lame 3.93.1, testing phase... (one week)

Reply #24 –
Agree...