On Fri, Nov 27, 2009 at 10:49 PM, Chris Bagwell <chris@cnpbagwell.com> wrote:


On Fri, Nov 27, 2009 at 10:42 PM, Doug Cook <idigdoug@users.sourceforge.net> wrote:


On Fri, Nov 27, 2009 at 6:51 PM, Chris Bagwell <chris@cnpbagwell.com> wrote:
I've currently marked lame 3.97 as deprecated in ChangeLog which gives it a 1 year life span at most.  If we need to we can reduce this to shorter period if mp3.c changes drastically soon.

Jim gave some ideas on what to do once support is removed... Hopefully, we will remember to look at mailing list archive when its time to remove and take the comments into account.

Chris

If this goes in immediately, we should probably not call this a dot release any more though to better reflect minimum versions changing.

Chris
 
Tracker patch 2870196  includes changes that improve support for LAME 3.97. Main point is to enable most of the ID3 tags to be set via the ID3 APIs supplied by 3.97. The current CVS code relies entirely on a function that was added in 3.98.1, but 90% of the ID3 support can be implemented using functions available in 3.97. Other change is to provide better fallback logic and better informational messages in the case where the current version of LAME doesn't support something (esp. important if using DL_OPEN since we don't know what version we're going to get in that case). Final change (for the non-dlopen case only) is to more accurately specify the autoconf variables needed for each situation. This calls for 3 autoconf variables to be used:
 

Thanks, Doug.  Today I've been trying to figure out current state of patches in tracker and at least close out the ones that seem to have already been merged into CVS.  I'll look into this specific patch and see if I can't incorporate it for 14.3.1 release.

I'm also trying to get DL_SNDFILE working with autoconf... Its got a couple of issues still in my initial attempt but they should be easy to fix.

Chris

OK, I just committed that patch to CVS.  Makes code read much nicer having HAVE_LAME_398 type #defines.

I have only one minor concern.  For mad precision, we may want to keep it at 16-bits even though we read in higher.  The reason is pretty simple.  Users expect the following command line:

sox infile.mp3 outfile.wav

to create a 16-bit WAV file instead of a 24-bit... Similar to how:

madplay -o outfile.wav infile.mp3

would create a 16-bit file.  If they want increased percision then they could do:

sox infile.mp3 -3 outfile.wav

Opinions?

Chris