IPB

Welcome Guest ( Log In | Register )

5 Pages V   1 2 3 > »   
Closed TopicStart new topic
Plans For --alt-presets, Etc, In Lame 3.93
Dibrom
post Oct 10 2002, 04:12
Post #1


Founder


Group: Admin
Posts: 2958
Joined: 26-August 02
From: Nottingham, UK
Member No.: 1



It appears that a 3.93 release is fairly close now, but I think the following things need to happen before everyone decides that it is the appropriate time to do so:

1. Takehiro's code and fixes need to be merged, at least enabled on the --alt-presets. I plan on using his --substep code, and also he apparently made some significant fixes to pre-echo handling in the --alt-presets. These need to be in the next version.

2. I will use the --substep code in addition to other tweaks to create 2 more presets to provide lower bitrate alternatives to --alt-preset standard.

3. Some information in the --alt-preset help should be clarified.

4. Listening tests need to take place to verify that no samples have been degraded so far.

5. Tests of all original samples need to take place to pinpoint improvements and to find out where there are still problems.

6. With this data, maybe some more tuning can take place.

7. Retest remaining problem samples.

8. Shoot for a release.

I might have missed some stuff there, but I can't think of it atm.

I've just downloaded Takehiro's latest code and the current standard 3.93 from CVS, and plan to spend time this week and this weekend implementing these new presets and testing for quality. I'll probably be posting some builds here very soon (maybe tomorrow) and I hope that people can report their results to me. The new presets will be a bit experimental at first, so the more help testing, the better.

I'm not exactly sure how long this testing process will take, but I think it's important to have all of this stuff in place before another release is made.

Comments?
Go to the top of the page
+Quote Post
JohnV
post Oct 10 2002, 04:36
Post #2





Group: Developer
Posts: 2797
Joined: 22-September 01
Member No.: 6



Seems that the only real progress would be coming from Takehiro or from Takehiro's branch. It would be useless and stupid to release 3.93 without taking advantage of Takehiro's development.
Otherwise 3.93 will be just another trivial release which probably just makes things worse by breaking some --alt-preset modes which are now widely used and recommended in the net.

I hope that Takehiro's sub-step noiseshaping and changed/tuned attackthreshold for --alt-presets etc. are incorporated.

Also I'd like to know if the following fixes are in the main branch or not (they should be):
1. psymodel debug: nspsymodel initilization fix
2. pre-echo detection code fix for ns/gpsycho(for not vbr case)
3. DC current estimation fix
4. nspsytune long/short switching fix,
5. noise shaping debug: infamous -Z problem.
6. bit allocation debug: bit allocation for short block of monoural fix.

Some of them are as far as I know, but are they all?

Imo 3.93 shouldn't be just another trivial release which actually breakes --alt-preset fast, when there's potential for so much more. I hope also other Lame developers than only Takehiro can see this too.....

Lame 3.93 should go into beta state, the tweaking and testing should be done properly and after that the 3.93 stable could be released.


--------------------
Juha Laaksonheimo
Go to the top of the page
+Quote Post
Benjamin Lebsanf...
post Oct 10 2002, 05:27
Post #3





Group: Members
Posts: 761
Joined: 29-September 01
Member No.: 40



did anyone contact mark taylor or another developer who is responsible for the release ? You mentioned very important points the developers should really think about!!
Go to the top of the page
+Quote Post
JohnV
post Oct 10 2002, 05:52
Post #4





Group: Developer
Posts: 2797
Joined: 22-September 01
Member No.: 6



The problem with Lame development is that nobody really seems to be in charge..

I'm sure Gaby,Robert and Tak read this though, and I hope other developers like Alexander Leidinger and M. Taylor will be informed about this...

Actually I'm counting on the three developers I mentioned first, that they would do something about it, so that Lame 3.93, when it's released, wouldn't be another trivial release, like Lame 3.92 pretty much was...

We are ready to help by doing listening tests etc. I just downloaded Tak's branch latest compile.


--------------------
Juha Laaksonheimo
Go to the top of the page
+Quote Post
Negative Zero
post Oct 10 2002, 07:19
Post #5





Group: Members
Posts: 248
Joined: 16-March 02
From: Toronto, Ontario
Member No.: 1534



As an end user, I'm all for the idea of holding back LAME 3.93's official release until it has been tested to the degree that Dibrom and JohnV have suggested.


--------------------
http://www.welovetheiraqiinformationminister.com
"I triple-guarantee you this is the best web site ever!"
Go to the top of the page
+Quote Post
britannica
post Oct 10 2002, 09:38
Post #6





Group: Members
Posts: 67
Joined: 24-May 02
Member No.: 2113



It's good to know efforts are being made for 3.93 to be a useful upgrade rather than a rubber-stamped bug-fix, and shall be very grateful for a 'medium' preset for recording from D-Sat radio. Can I ask if the -Y switch will still serve as a lowpass filter in 3.93 ?

Go to the top of the page
+Quote Post
Gabriel
post Oct 10 2002, 10:04
Post #7


LAME developer


Group: Developer
Posts: 2950
Joined: 1-October 01
From: Nanterre, France
Member No.: 138



Alexander is (unofficially) in charge of the release process, as Mark do not seem to have any more time for Lame.

I personnaly prefer releasing often (if it does not break anything) than waiting a huge time in order to have a lot of changes. This way, the release process is easier.

I understand that you would like some substancial improvments for a new release.

I have a question: do you think the current 3.93 released as beta would be a dowgrade from 3.92? If no, then it means that it could be released as beta (could be, I didn't mentionned should be).
The plan was to release 3.93, then after this release merging Takehiro's branch into main branch.

I understand your point, but you need to also understand that what could appears as a "trivial" release is not a bad point, specially when a program need to be able to run under a whole range of different operatin systems.
Go to the top of the page
+Quote Post
kjempen
post Oct 10 2002, 10:56
Post #8





Group: Members
Posts: 137
Joined: 3-October 01
Member No.: 193



How about voting over it, to see what users want?
Go to the top of the page
+Quote Post
Guest_SK1_*
post Oct 10 2002, 11:14
Post #9





Guests






... I think Dibrom's and JohnV's suggestions are very right.
It will be a great senseless waste to release a new 3.93 version that doesn't include those VERY important additions/modifications.
I don't think any voting is needed.
Go to the top of the page
+Quote Post
dev0
post Oct 10 2002, 15:26
Post #10





Group: Developer
Posts: 1679
Joined: 23-December 01
From: Germany
Member No.: 731



Looks like quite a lot changes to me (compared to 3.90 -> 3.91 -> 3.92), so I'd go with 3.93BETA, see hwo it performs for say one or two month and than move over to 3.93.
dev0


--------------------
"To understand me, you'll have to swallow a world." Or maybe your words.
Go to the top of the page
+Quote Post
Dibrom
post Oct 10 2002, 17:59
Post #11


Founder


Group: Admin
Posts: 2958
Joined: 26-August 02
From: Nottingham, UK
Member No.: 1



QUOTE
I personnaly prefer releasing often (if it does not break anything) than waiting a huge time in order to have a lot of changes. This way, the release process is easier.


I don't really see the point in making a release just for the sake of having a new release in X amount of time. Releases should be dictated by the merit of their improvements otherwise it's just arbitrary and could easily cause more problems than it fixes.

QUOTE
I have a question: do you think the current 3.93 released as beta would be a dowgrade from 3.92? If no, then it means that it could be released as beta (could be, I didn't mentionned should be).
The plan was to release 3.93, then after this release merging Takehiro's branch into main branch.


I don't know, but the fact that you apparently are not sure either (since you asked) should be reason enough not to release now. The point is that changes were made which could have an effect on the quality of what are some of the most widely used settings -- settings which people count on to be as good as possible and to have been tested properly.

Making a release without proper testing would be very irresponsible IMO. LAME has traditionally suffered very poor QA, let's not continue the trend if possible.

QUOTE
I understand your point, but you need to also understand that what could appears as a "trivial" release is not a bad point, specially when a program need to be able to run under a whole range of different operatin systems.


It's a bad point if it is simply arbitrary, and it's doubly bad if it's arbitrary and untested. As I said before, it's just irresponsible really.

I don't understand what you mean about "when a program need to be able to run under a whole range of different operating systems." Does 3.92 have some major problems preventing it from running on most major operating systems?

The only thing I see in the changelog so far are portability fixes for Tru64 Unix and SunOS 4.x. How many people are those fixes going to affect vs how many people poor quality testing could affect?

Oh, and one last thing, if Alexander is the release manager now, maybe you could ask him to come by here sometime. A lot of the most hardcore (and concerned and active) users of LAME frequent this board. It'd be helpful for him participate in some of their discussions I think wink.gif

I would tell him myself, but I unsubscribed from the list some time ago...
Go to the top of the page
+Quote Post
Oge_user
post Oct 10 2002, 18:39
Post #12


A/V Moderator


Group: Members
Posts: 317
Joined: 20-August 02
Member No.: 3123



Why don't take in consideration a new/better lowpass filter
in future versions of Lame?
Maybe Similar to the Cool Edit Pro's lowpass filter?


--------------------
[ Commodore 64 Forever...! ]
Go to the top of the page
+Quote Post
Dibrom
post Oct 10 2002, 23:49
Post #13


Founder


Group: Admin
Posts: 2958
Joined: 26-August 02
From: Nottingham, UK
Member No.: 1



Gabriel:

Have you been testing the --alt-preset medium you have come up with for quality? If it's going to be in 3.93, and if 3.93 is going to be released without all of these other changes I mentioned, have you at least made sure that this preset will live up to expectations?

If not, you might want to consider putting a disclaimer on it that it hasn't been tested... after all, the help for the --alt-presets even says that they are the most tested and highest quality settings available for LAME. Including a largely haphazard and untested preset (if that is so, I don't know which tests you have done) will probably do more harm than good.

Btw, I'm going to try and upload a test version of Takehiro's branch with 2 more alt-presets today for people to test..
Go to the top of the page
+Quote Post
ezra2323
post Oct 11 2002, 00:08
Post #14





Group: Members
Posts: 586
Joined: 17-July 02
Member No.: 2631



As an end user, just wanted to say thanks to all the developers.

I am REALLY looking forward to a 'lower bit rate' alt preset. While the -Y switch is cool (no quality reduction that I can hear), the file sizes are still too big (about 180 avg) for portability use. An optimized VBR setting to take that number down to the 140-150 range will be awesome!
Go to the top of the page
+Quote Post
Dibrom
post Oct 11 2002, 04:10
Post #15


Founder


Group: Admin
Posts: 2958
Joined: 26-August 02
From: Nottingham, UK
Member No.: 1



Ok... here's the binary, as promised:

The following new presets have been added:

--alt-preset dm-medium

--alt-preset portable

--alt-preset dm-radio

The dm parts are in there so they aren't confused with current presets. Naming is just temporary. The presets are in order of quality from highest with medium to lowest with radio. I haven't done any sort of extensive testing yet, only a little bit to make sure things were working at all.

What I need people to do is download this binary and test it. Bitrates for the various presets across many albums or something like that would be very helpful. Same thing goes for quality. While these presets probably wont be transparent, I'd still like to know about quality issues, especially if there's a really harsh artifact you're hearing.

What I'm trying to shoot for bitrate wise is:

180kbps

160kbps

140kbps

for the respective presets. This will probably take some more tuning, so that's why bitrate information would be great. Also, test --alt-preset standard against 3.90.2 or 3.92 if you could. That would be good as well. If there were samples you had where 3.92 had problems before, they might be fixed now.

The 180kbps preset should be higher quality than --r3mix without question. I'm shooting for the 160kbps one to be also, and maybe the 140kbps one as well. If you'd like to compare these presets that would be fine.

Oh, and there's no fast modes for any of the new presets right now. If I have time, I'll try to add these later, but no promises. I tried initially to do this but ran into some problems and didn't have time to figure out what the cause was.
Go to the top of the page
+Quote Post
Dibrom
post Oct 11 2002, 04:53
Post #16


Founder


Group: Admin
Posts: 2958
Joined: 26-August 02
From: Nottingham, UK
Member No.: 1



Just a small update... the .dll is needed by this compile because I had to build it using cygwin. This also means the compile is painfully slow.. heh. I'm going to try and post an ICL compile tomorrow, along with the modified sources.

Also, there's a few things I forgot to do in my modifications which should be able to further reduce the bitrate on the lower presets without impacting quality too much...
Go to the top of the page
+Quote Post
flloyd
post Oct 11 2002, 04:56
Post #17





Group: Members
Posts: 131
Joined: 3-October 02
From: Santa Monica, CA
Member No.: 3472



Hi, I noticed that --r3mix is still in LAME (or at least in --longhelp). Have we thought about disabling it and popping up a message to use preset standard or preset medium instead. I remember this being suggested early this summer but people objected because r3mix produces smaller files than preset standard but now that there are more options maybe this will make that argument invalid and we can encourage people to step up to a higher quality MP3. biggrin.gif

Just a thought, in the end it pretty much has no effect on me but hopefully helps others.


--------------------
Sorry, I have nothing witty to say here.
Go to the top of the page
+Quote Post
Dibrom
post Oct 11 2002, 05:04
Post #18


Founder


Group: Admin
Posts: 2958
Joined: 26-August 02
From: Nottingham, UK
Member No.: 1



QUOTE (flloyd @ Oct 10 2002 - 08:56 PM)
Hi, I noticed that --r3mix is still in LAME (or at least in --longhelp). Have we thought about disabling it and popping up a message to use preset standard or preset medium instead. I remember this being suggested early this summer but people objected because r3mix produces smaller files than preset standard but now that there are more options maybe this will make that argument invalid and we can encourage people to step up to a higher quality MP3.  biggrin.gif

Just a thought, in the end it pretty much has no effect on me but hopefully helps others.

I pretty much agree with this idea. I think once tuning of the new presets is pretty solid, --r3mix should be either removed or aliased to one of the similar bitrate --alt-presets.
Go to the top of the page
+Quote Post
ff123
post Oct 11 2002, 05:25
Post #19


ABC/HR developer, ff123.net admin


Group: Developer (Donating)
Posts: 1396
Joined: 24-September 01
Member No.: 12



tak3lame.exe attempts to communicate with something (which my firewall detects). Why does it do this?

ff123
Go to the top of the page
+Quote Post
Dibrom
post Oct 11 2002, 05:30
Post #20


Founder


Group: Admin
Posts: 2958
Joined: 26-August 02
From: Nottingham, UK
Member No.: 1



QUOTE (ff123 @ Oct 10 2002 - 09:25 PM)
tak3lame.exe attempts to communicate with something (which my firewall detects).  Why does it do this?

ff123

Hrmm...

Are you sure about this? Do you know what it was trying to communicate with? To my knowledge, this shouldn't happen. Maybe it's something in the cygwin.dll which your firewall doesn't like?
Go to the top of the page
+Quote Post
ff123
post Oct 11 2002, 06:01
Post #21


ABC/HR developer, ff123.net admin


Group: Developer (Donating)
Posts: 1396
Joined: 24-September 01
Member No.: 12



QUOTE (Dibrom @ Oct 10 2002 - 08:30 PM)
QUOTE (ff123 @ Oct 10 2002 - 09:25 PM)
tak3lame.exe attempts to communicate with something (which my firewall detects).  Why does it do this?

ff123

Hrmm...

Are you sure about this? Do you know what it was trying to communicate with? To my knowledge, this shouldn't happen. Maybe it's something in the cygwin.dll which your firewall doesn't like?

I can't track it down to what it's trying to talk to, but I verified that it does try (at least according to Conseal, my firewall). I also just scanned my system for viruses and spyware (I'm clean).

ff123
Go to the top of the page
+Quote Post
Dibrom
post Oct 11 2002, 06:06
Post #22


Founder


Group: Admin
Posts: 2958
Joined: 26-August 02
From: Nottingham, UK
Member No.: 1



ff123:

Very strange. I don't know what to say.. it must be something with cygwin. I can't imagine it would be something malicious though. I'll be providing a non-cygwin compile tomorrow hopefully though, so it shouldn't be an issue then.
Go to the top of the page
+Quote Post
harashin
post Oct 11 2002, 07:08
Post #23





Group: Members
Posts: 339
Joined: 20-February 02
From: Kyoto, Japan
Member No.: 1362



tak3lame.exe seems to use qval=3 as standard. Should I use presets with -h?


--------------------
Folding@Home Hydrogenaudio.org Team ID# 32639
http://folding.stanford.edu/
Go to the top of the page
+Quote Post
ChS
post Oct 11 2002, 07:41
Post #24





Group: Members
Posts: 247
Joined: 26-January 02
Member No.: 1172



I've encoded one CD (Halford - Resurrection) with the various presets so far and here's how the average bitrates go:

--alt-preset dm-medium: 163 kbps
--alt-preset dm portable: 162 kbps
--alt-preset dm-radio: 149 kbps
--alt-preset standard 3.90.2: 223 kbps


Resurrection is a Metal CD, from 2000. For a track by track summary of bitrates, you can look at this page.
Go to the top of the page
+Quote Post
Gabriel
post Oct 11 2002, 08:35
Post #25


LAME developer


Group: Developer
Posts: 2950
Joined: 1-October 01
From: Nanterre, France
Member No.: 138



Dibrom, I think that you should subscribe to lame-dev and lame-cvs lists, at least in digest mode.

About the release date:
I would like you to understand that it is better to release more often with small changes, than releasing only once a year with major changes. In the second way, the release process is often harder due to portability problems.
That is why I am suggesting a compromise:
Let's try to focus on a release date around november 15th. This probably means less changes that what you were thinking about, in order to have less new features, but solid new features.
Do you agree on this proposal?

About --preset r3mix:
It is there for compatibility. I'd like to alias it to another preset when we'll have a preset similar in bitrate.

about --preset medium:
I used it on several albums, and I like the results (according to the produced bitrate). Of course it is not fully tested, and I was planning to not include it into the doc.


Preset names:
I think that a "radio" preset should perhaps focus on lower bitrates. That is not a big issue, but how would we call a proset focussing on 80-100kbps?

Takehiro's branch: if we agree on the 1 month delay, I think that we should merge Takehiro's branch into main.
Go to the top of the page
+Quote Post

5 Pages V   1 2 3 > » 
Closed TopicStart new topic
1 User(s) are reading this topic (1 Guests and 0 Anonymous Users)
0 Members:

 



RSS Lo-Fi Version Time is now: 29th December 2014 - 06:41