From: Gabriel B. <bou...@mp...> - 2002-10-11 09:10:33
|
> Gabriel Bouvigne wrote: > > I am discussing if we should release now or wait a little more with people > > on the Hydrogenaudio forum. > > I will give you a summary of things discussed soon. > > I will try to have a look at the forum today. > > > Basically Dibrom would like to wait a lot more in order to have new > > features, and I am trying to reach a consensus focusing on a release date > > around nov, 15th, with less features in order to comply with this date. > > I'm thinking about a release as soon as possible and about another > (beta) release soon after 3.93. Takehiro has a lot of work in his branch > and we may want to merge it (depending on what Takehiro thinks about it) > and make a beta release... What do you think about this? I was also initially thinking about a release as soon as possible. But Dibrom and Takehiro have some valid points: The current fast presets are a little broken. This point can be considered as a stopping factor. (Without it I would have no doubt about a release now) We would need to fix it before releasing. However, Takehiro's branch is hanlding fast presets a little better than the main branch. So this would be extra work to fix fast presets in the main branch, and this would be a "waste" if we merge Takehiro's branch just after. So my suggestions is: *merge Takehiro's branch now *focus on fixing current presets *focus on a release aroun nov, 15th (1 extra month due to the merge of branchs and the need for testing) If there is enough time, perhaps introduce new presets, but this would not be a priority. (I am cc'ing this mail to lame-dev and HA forum) Regards, ---- Gabriel Bouvigne www.mp3-tech.org personal page: http://gabriel.mp3-tech.org |
From: Takehiro T. <tak...@in...> - 2002-10-14 18:22:40
|
>>>>> "T" == Takehiro Tominaga <tak...@in...> writes: T> I just made a new branch, "takehiro-stable_2002_10_15", forked OOPS, sorry, it should be "takehiro-stable-2002_10_15". -- Takehiro TOMINAGA // may the source be with you! |
From: Robert H. <Rob...@gm...> - 2002-10-14 19:51:48
|
Hi Takehiro Am Montag, 14. Oktober 2002 20:22 schrieb Takehiro Tominaga: > >>>>> "T" == Takehiro Tominaga <tak...@in...> writes: > > T> I just made a new branch, "takehiro-stable_2002_10_15", forked > > OOPS, sorry, it should be "takehiro-stable-2002_10_15". some remarks: does not compile on Win32 FLOAT_MAX isn't defined in psymodel.c sys/parm.h issue in main.h some pinfo not out defined in lame.c What's your development branch now? Ciao Robert |
From: Gabriel B. <bou...@mp...> - 2002-10-15 06:43:23
|
> some remarks: does not compile on Win32 > FLOAT_MAX isn't defined in psymodel.c > sys/parm.h issue in main.h > some pinfo not out defined in lame.c This should be defined in limits.h under win32 (but also under linux) Regards, ---- Gabriel Bouvigne www.mp3-tech.org personal page: http://gabriel.mp3-tech.org |
From: Takehiro T. <tak...@in...> - 2002-10-15 15:49:30
|
>some remarks: does not compile on Win32 >FLOAT_MAX isn't defined in psymodel.c I made another thread. see it. >sys/parm.h issue in main.h Thanks, I fixed it (at least it works, I hope ;p). Better way is of course what Alex has done on mainline. I will merge it in a short time. >some pinfo not out defined in lame.c fixed, I hope. -- Takehiro TOMINAGA // may the source be with you! |
From: Gabriel B. <bou...@mp...> - 2002-10-15 06:40:50
|
> I am so lazy to read the whole of discussion on HA, but I propose > replace main branch with this branch. Yes, "REPLACE" it. > > Moreover, the way to "MERGE" is too heavy task, making many patches > from big diff is not easy and tend to make a bug. > > So the "MERGE" is only wasting time. I prefer "REPLACE". Yes, merging using incremental patches should be time consuming. I have a suggestion: *Tag 3.93 (when ready) *merge main into your new branch *replace main branch with your new branch *release both 3.93 stable and 3.94beta at the same time Regards, ---- Gabriel Bouvigne www.mp3-tech.org personal page: http://gabriel.mp3-tech.org |
From: Alexander L. <Alexander@Leidinger.net> - 2002-10-16 12:38:01
|
On Tue, 15 Oct 2002 08:40:40 +0200 "Gabriel Bouvigne" <bou...@mp...> wrote: > I have a suggestion: > *Tag 3.93 (when ready) > *merge main into your new branch > *replace main branch with your new branch > *release both 3.93 stable and 3.94beta at the same time Why doe we need to release both at the same day? What's wrong with bringing the actual code in a good shape, tagging it, releasing it, and then merging Takehiros work? Bye, Alexander. -- Yes, I've heard of "decaf." What's your point? http://www.Leidinger.net Alexander @ Leidinger.net GPG fingerprint = C518 BC70 E67F 143F BE91 3365 79E2 9C60 B006 3FE7 |
From: Gabriel B. <bou...@mp...> - 2002-10-16 08:26:44
|
> > > OOPS, sorry, it should be "takehiro-stable-2002_10_15". > > one more open problem, the DLL can not get compiled due to the usage > of now removed API functions. Probably the set/get padding. I think that those functions should stay, even empty, for compatibility until Lame 4.0 Regards, ---- Gabriel Bouvigne www.mp3-tech.org personal page: http://gabriel.mp3-tech.org |
From: Alexander L. <Alexander@Leidinger.net> - 2002-10-16 12:39:16
|
On Wed, 16 Oct 2002 09:59:44 +0200 "Gabriel Bouvigne" <bou...@mp...> wrote: > > > > OOPS, sorry, it should be "takehiro-stable-2002_10_15". > > > > one more open problem, the DLL can not get compiled due to the usage > > of now removed API functions. > > Probably the set/get padding. > I think that those functions should stay, even empty, for compatibility > until Lame 4.0 Yes, this is the way to go. Bye, Alexander. -- "One world, one web, one program" -- Microsoft promotional ad "Ein Volk, ein Reich, ein Fuehrer" -- Adolf Hitler http://www.Leidinger.net Alexander @ Leidinger.net GPG fingerprint = C518 BC70 E67F 143F BE91 3365 79E2 9C60 B006 3FE7 |
From: Robert H. <Rob...@gm...> - 2002-10-25 09:04:10
|
Hi Dominique, Am Freitag, 25. Oktober 2002 10:14 schrieb Dominique Duvivier: > Hi Robert, > > That would be my fault, in fact... > > Is this problem present in the main branch as well ? > > I'm not sure if the fast_log2 routine handles invalid > input (ie negative numbers) well, but I would call it > a bug in the calling part if that was the case... > > Have you more information on this floating point > exception ? > > > Thanks > > Dom the main branch handles those cases well. I don't think it's your fault. I had no time for debugging yet. One problem sample can be found there: http://home.arcor.de/rhegemann/Hobbit.wav Ciao Robert |
From: Alexander L. <Alexander@Leidinger.net> - 2002-10-11 09:16:42
|
Gabriel Bouvigne wrote: > So my suggestions is: > *merge Takehiro's branch now > *focus on fixing current presets > *focus on a release aroun nov, 15th (1 extra month due to the merge of > branchs and the need for testing) > > If there is enough time, perhaps introduce new presets, but this would not > be a priority. I just registered at HA, I will write a large response there. Bye, Alexander. |
From: Takehiro T. <tak...@in...> - 2002-10-14 17:52:18
|
I just made a new branch, "takehiro-stable_2002_10_15", forked from my experimental branch. I think current status of this branch is pretty stable and has better quality than the mainline (at least for me), and all the patches in the mainline branch are applied. Once I said "my branch is not ready for merging", on HA. But with all the holidays in this weekend (in Japan, there are three consecutive holidays:p), I cleaned up and checked my branch, to make it more stable, rather than adding new functionality. And my work result in this branch. >>>>> "G" == Gabriel Bouvigne <bou...@mp...> writes: G> However, Takehiro's branch is hanlding fast presets a little G> better than the main branch. So this would be extra work to fix G> fast presets in the main branch, and this would be a "waste" if G> we merge Takehiro's branch just after. Yes, I agree. G> So my suggestions is: G> *merge Takehiro's branch now G> *focus on fixing current presets G> *focus on a release aroun nov, 15th I am so lazy to read the whole of discussion on HA, but I propose replace main branch with this branch. Yes, "REPLACE" it. I wonder how many people attempt to join the merge process. Once I mailed the 4 psymodel patches, one of which contained bug. No one noticed it, and I desperated the LAME-dev. Moreover, the way to "MERGE" is too heavy task, making many patches from big diff is not easy and tend to make a bug. So the "MERGE" is only wasting time. I prefer "REPLACE". Any comments ? -- Takehiro TOMINAGA // may the source be with you! |
From: Alexander L. <Alexander@Leidinger.net> - 2002-10-14 20:19:12
|
On Tue, 15 Oct 2002 02:52:38 +0900 (JST) Takehiro Tominaga <tak...@in...> wrote: > I just made a new branch, "takehiro-stable_2002_10_15", forked from > my experimental branch. I think current status of this branch is IMHO it would have been enough if you just tagged the files on your branch. > Moreover, the way to "MERGE" is too heavy task, making many patches > from big diff is not easy and tend to make a bug. > > So the "MERGE" is only wasting time. I prefer "REPLACE". Are you sure we don't loose something? Just have a look at the file ChangeLog and compare the commits to both branches. If you find a corresponding commit for an entry for the head branch in your branch, then everything is fine, but if not, you have to look at it. I would also like to make a stable release with the current code (after someone fixed the fast preset), and after that a beta release with your code (on the same day or at another day, I don't mind). Would this be ok for you? This would also give you a little bit more time to review the ChangeLog file. What do you mean by "replace"? Checking out the head branch, overwritting the files with your versions, commiting it and removing superfluous files? Bye, Alexander. -- ...and that is how we know the Earth to be banana-shaped. http://www.Leidinger.net Alexander @ Leidinger.net GPG fingerprint = C518 BC70 E67F 143F BE91 3365 79E2 9C60 B006 3FE7 |
From: Robert H. <Rob...@gm...> - 2002-10-14 20:45:11
|
Am Montag, 14. Oktober 2002 22:18 schrieb Alexander Leidinger: > > So the "MERGE" is only wasting time. I prefer "REPLACE". > > Are you sure we don't loose something? Just have a look at the file > ChangeLog and compare the commits to both branches. If you find a > corresponding commit for an entry for the head branch in your branch, > then everything is fine, but if not, you have to look at it. > > I would also like to make a stable release with the current code (after > someone fixed the fast preset), and after that a beta release with your > code (on the same day or at another day, I don't mind). Would this be ok > for you? This would also give you a little bit more time to review the > ChangeLog file. > > What do you mean by "replace"? Checking out the head branch, > overwritting the files with your versions, commiting it and removing > superfluous files? most likely yes. Seems like Takehiro's branch will bring us changes in the API. At this time we should take some closer look at it and probably do some more changes, in sake of a smaller interface with less possibilities to get it wrong. > Bye, > Alexander. Ciao Robert |
From: Robert H. <Rob...@gm...> - 2002-10-15 08:56:20
|
Am Montag, 14. Oktober 2002 20:22 schrieb Takehiro Tominaga: > >>>>> "T" == Takehiro Tominaga <tak...@in...> writes: > > T> I just made a new branch, "takehiro-stable_2002_10_15", forked > > OOPS, sorry, it should be "takehiro-stable-2002_10_15". following doesn't work: --vbr-new -Y => results in floating point exception --remix => reported to be screwed up I hope to find some time this evening to take a look the vbr new -Y issue. Ciao Robert |
From: Takehiro T. <tak...@in...> - 2002-10-15 17:12:42
|
>>>>> "R" == Robert Hegemann <Rob...@gm...> writes: R> --vbr-new -Y => results in floating point exception On my environment, "assertion failure" is happen > ./frontend/lame --vbr-new -Y ~/wav/si04.wav /dev/null : lame: bitstream.c:508: Assertion `tableindex < 32u' failed. seems its bit hard to find out the problem. R> --remix => reported to be screwed up (--r3mix ?) fixed, I hope. Thanks Robert, I forgot to test --vbr-new comprehensively, except --preset fast XXXX. -- Takehiro TOMINAGA // may the source be with you! |
From: Robert H. <Rob...@gm...> - 2002-10-15 21:34:38
|
Hi Takehiro, Am Dienstag, 15. Oktober 2002 19:13 schrieb Takehiro Tominaga: > >>>>> "R" == Robert Hegemann <Rob...@gm...> writes: > > R> --vbr-new -Y => results in floating point exception > > On my environment, "assertion failure" is happen > > > ./frontend/lame --vbr-new -Y ~/wav/si04.wav /dev/null > > lame: bitstream.c:508: Assertion `tableindex < 32u' failed. > > seems its bit hard to find out the problem. I've just committed a patch for the -Y bug. The problem was, the xr34 values weren't correct for sfb21 anymore. Ciao Robert |
From: Robert H. <Rob...@gm...> - 2002-10-23 23:51:41
|
Hi all! Takehiro I added mid side channel sparsing to your stable branch. --ms-sparsing n will activate sparsing if n = 1 or 2, disabling for n = 0 (default) --ms-sparse-low x sets threshold for lower frequencies to x dB, default 9 dB --ms-sparse-high x sets threshold for higher frequencies to x dB, default 3 dB Ciao Robert |
From: Gabriel B. <bou...@mp...> - 2002-10-24 06:59:49
|
> Takehiro I added mid side channel sparsing to your stable > branch. > > --ms-sparsing n > will activate sparsing if n = 1 or 2, disabling for n = 0 (default) > > --ms-sparse-low x > sets threshold for lower frequencies to x dB, default 9 dB > > --ms-sparse-high x > sets threshold for higher frequencies to x dB, default 3 dB Is it possible to select the low and high limits? I tryed "extreme sparsing" for very low bitrates, and was pleased by the result. Basically from the middle sfb up to the max, I totally removed the side channel, resulting in a mono high freq part. Of course if we go in that "extreme sparsing" it would be better to add IS position, but that was for testing. The problem was that in this case there were artifacts due to L/R to M/S switching, as when the frames are L/R, the higher part is not mono. So I used forced MS. It increased the bitrate, but even with this increase the overall bit demand was lower due to the higher freq mono part. This is not a "clean" thing, but gives a good idea of the potential IS gain. ---- Gabriel Bouvigne www.mp3-tech.org personal page: http://gabriel.mp3-tech.org |
From: Robert H. <Rob...@gm...> - 2002-10-24 23:34:13
|
Hi all! Takehiro I'm still getting floating point exceptions from time to time, calling lame with --vbr-old --nspsytune. I don't get them if I undefine USE_FAST_LOG. Seems as if the fast_log2 routine needs some debugging. Ciao Robert |
From: Robert H. <Rob...@gm...> - 2002-10-15 22:56:32
|
Am Dienstag, 15. Oktober 2002 10:56 schrieb Robert Hegemann: > Am Montag, 14. Oktober 2002 20:22 schrieb Takehiro Tominaga: > > >>>>> "T" == Takehiro Tominaga <tak...@in...> writes: > > > > T> I just made a new branch, "takehiro-stable_2002_10_15", forked > > > > OOPS, sorry, it should be "takehiro-stable-2002_10_15". one more open problem, the DLL can not get compiled due to the usage of now removed API functions. Ciao Robert |
From: Takehiro T. <tak...@in...> - 2002-10-15 15:31:25
|
>>>>> "R" == Robert Hegemann <Rob...@gm...> writes: R> some remarks: does not compile on Win32 R> FLOAT_MAX isn't defined in psymodel.c uuuuum.... FLOAT_MAX is defined in machine.h. This is same as the mainline. #if ( defined(_MSC_VER) || defined(__BORLANDC__) || defined(__MINGW32__) ) # define WIN32_LEAN_AND_MEAN # include <windows.h> #else # ifndef FLOAT typedef float FLOAT; # ifdef FLT_MAX # define FLOAT_MAX FLT_MAX # else # define FLOAT_MAX 1e99 /* approx */ # endif # endif #endif But I think this is completely screwed up. 1. if FLOAT is float, FLOAT_MAX should be arround 1e37, not 1e99. 2. on a Windows environment, it seems <windows.h> does not define the FLOAT_MAX. so I think the code should be #if ( defined(_MSC_VER) || defined(__BORLANDC__) || defined(__MINGW32__) ) # define WIN32_LEAN_AND_MEAN # include <windows.h> #endif #ifndef FLOAT typedef float FLOAT; # ifdef FLT_MAX # define FLOAT_MAX FLT_MAX # else # define FLOAT_MAX 1e37 /* approx */ # endif #endif I commited this change in my experimental branch. Could someone can check this ? -- Takehiro TOMINAGA // may the source be with you! |
From: Robert H. <Rob...@gm...> - 2002-10-15 16:24:19
|
well, in VC environment FLT_MAX is defined in float.h Ciao Robert |
From: Gabriel B. <bou...@mp...> - 2002-10-16 08:26:43
|
> R> some remarks: does not compile on Win32 > R> FLOAT_MAX isn't defined in psymodel.c > > uuuuum.... > > FLOAT_MAX is defined in machine.h. This is same as the mainline. Shouldn't FLOAT_MAX always be defined in limits.h in every platform? |
From: Robert H. <Rob...@gm...> - 2002-10-16 09:06:41
|
Hi Gabriel, Am Mittwoch, 16. Oktober 2002 09:55 schrieb Gabriel Bouvigne: > > R> some remarks: does not compile on Win32 > > R> FLOAT_MAX isn't defined in psymodel.c > > > > uuuuum.... > > > > FLOAT_MAX is defined in machine.h. This is same as the mainline. > > Shouldn't FLOAT_MAX always be defined in limits.h in every platform? it looks like in limits.h are only integral values defined. no floating point, but in float.h . (speaking about MS VC) #if ( defined(_MSC_VER) || defined(__BORLANDC__) || defined(__MINGW32__) ) # define WIN32_LEAN_AND_MEAN # include <windows.h> # include <float.h> # define FLOAT_MAX FLT_MAX #else # ifndef FLOAT typedef float FLOAT; # ifdef FLT_MAX # define FLOAT_MAX FLT_MAX # else # define FLOAT_MAX 1e38 /* approx */ # endif # endif #endif Ciao Robert |