Re: [MP3 ENCODER] TagItem issues...
On 25 Sep, Sigbjørn Skjæret wrote: simply making a new TagItems interface which allows you to specify the type of data the TagItem contains. This will be much better in the long run, and will allow the TagItems to contain any type of data. This sounds more complex than my proposed "void*" change. Keep in mind: More complex, but not that hard. "KISS". I'm not even gonna ask. ;) ---snip--- KISS Principle /kis' prin'si-pl/ n. "Keep It Simple, Stupid". A maxim often invoked when discussing design to fend off creeping featurism and control development complexity. Possibly related to the marketroid maxim on sales presentations, "Keep It Short and Simple". ---snip--- Bye, Alexander. -- I believe the technical term is "Oops!" http://www.Leidinger.net Alexander @ Leidinger.net GPG fingerprint = 7423 F3E6 3A7E B334 A9CC B10A 1F5F 130A A638 6E7E -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] TagItem issues...
On 24 Sep, Sigbjørn Skjæret wrote: 1.) Floats and doubles will lose all it's precision (this can be simply avoided by passing the string-pointer from arg-parsing and converting when parsing TagItems instead) What about passing the pointer to the float/double instead? Sure, but that means you will have to temporarily store the value somewhere else. Yes. Are there many fixed values in lame? simply making a new TagItems interface which allows you to specify the type of data the TagItem contains. This will be much better in the long run, and will allow the TagItems to contain any type of data. This sounds more complex than my proposed "void*" change. Keep in mind: More complex, but not that hard. "KISS". the Amiga TagItem implementation was done with 32bit pointers in mind and not with portability. An (IMHO) more elegant (and still simple) solution for the data part would look like [...] The first proposal is IMHO enough for everyday use, the second is for architectures which didn't allow lossless transportation of information between a void* and an integer type (in case you use ti_data to contain the information instead of a pointer to the information). Only "problem" I can see immediately with void* is that all values needs to be casted, which wasn't strictly necessary with unsigned long, and float/ double still needs to be temporarily stored. :P I'm waiting for your solution which didn't need casts (and remember the mail which talked about casts in lame). Bye, Alexander. -- Intel: where Quality is job number 0.9998782345! http://www.Leidinger.net Alexander @ Leidinger.net GPG fingerprint = 7423 F3E6 3A7E B334 A9CC B10A 1F5F 130A A638 6E7E -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] TagItem issues...
On 23 Sep, Sigbjørn Skjæret wrote:
Ok, after thinking about this for a while, and experimenting a little, I
thought of a couple of issues with using TagItems to pass configuration
settings in LAME...
1.) Floats and doubles will lose all it's precision (this can be simply
avoided by passing the string-pointer from arg-parsing and converting
when parsing TagItems instead)
What about passing the pointer to the float/double instead?
3.) 64bit pointers will be truncated (not too much trouble unless you have
and use more than 4gig of memory in your machine).
Don't keep the AmigaOS compatibility of my functions (see bellow why)
and change the data part (ti_Data) of the struct to "void*".
I've been thinking about simply ditching AmigaOS TagItem compatability, and
I think there's no need to use any Amiga library in the LAME library, so
it didn't buys you anything to keep the compatibility (or use the real
Amiga functions). If you improve the usability of the LAME TagItem
(like) implementation then go for it.
simply making a new TagItems interface which allows you to specify the type
of data the TagItem contains. This will be much better in the long run, and
will allow the TagItems to contain any type of data.
This sounds more complex than my proposed "void*" change. Keep in mind:
the Amiga TagItem implementation was done with 32bit pointers in mind
and not with portability. An (IMHO) more elegant (and still simple)
solution for the data part would look like
void *ti_data;
or
union { void *pointer; unsigned long number; } ti_data;
instead of just
unsigned long ti_data;
The first proposal is IMHO enough for everyday use, the second is for
architectures which didn't allow lossless transportation of information
between a void* and an integer type (in case you use ti_data to contain
the information instead of a pointer to the information).
Bye,
Alexander.
--
The dark ages were caused by the Y1K problem.
http://www.Leidinger.net Alexander @ Leidinger.net
GPG fingerprint = 7423 F3E6 3A7E B334 A9CC B10A 1F5F 130A A638 6E7E
--
MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] LAME as a shared lib
On 20 Sep, Mark Taylor wrote: 1) use commandline like strings to setup LAME's encoding engine handle = lame_get_handle(); lame_setup_stuff(handle, "output samplerate = 32 kHz"); lame_setup_stuff(handle, "input samplerate = 48 kHz"); lame_setup_stuff(handle, "bitrate = 128 kps"); or in an Amiga TagItem like way (I have an implementation (~2k source, most of it are comments) of struct TagItem and NextTagItem() if you need it), less difficult to use (you didn't need a parser). And how about volunteering to add this to LAME? :-) NextTagItem() (no problem, .gz or .bz2?) or lame_setup_stuff() (sorry, not enough spare time at the moment)? Bye, Alexander. -- Reboot America. http://www.Leidinger.net Alexander @ Leidinger.net GPG fingerprint = 7423 F3E6 3A7E B334 A9CC B10A 1F5F 130A A638 6E7E -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] LAME as a shared lib
On 18 Sep, Robert Hegemann wrote: A much better (and tidier) solution is to have one function that you can pass a struct to, like this: lame_setup_stuff(struct LAMEprefs *prefs, unsigned int structsize); OR: 1)use commandline like strings to setup LAME's encoding engine handle = lame_get_handle(); lame_setup_stuff(handle, "output samplerate = 32 kHz"); lame_setup_stuff(handle, "input samplerate = 48 kHz"); lame_setup_stuff(handle, "bitrate = 128 kps"); or in an Amiga TagItem like way (I have an implementation (~2k source, most of it are comments) of struct TagItem and NextTagItem() if you need it), less difficult to use (you didn't need a parser). Bye, Alexander. -- The dark ages were caused by the Y1K problem. http://www.Leidinger.net Alexander @ Leidinger.net GPG fingerprint = 7423 F3E6 3A7E B334 A9CC B10A 1F5F 130A A638 6E7E -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] LAME style guide, rule #1
On 10 Sep, Mark Taylor wrote: Changing them makes life very difficult for people (like myself) who try to keep up with *important* changes. When the MP3 output has changed, it is usefull to track down why it has changed, and thus code changes (which do not represent bug fixes or additional functionality) should be kept to a minimum. Why don't you establish some rules: - "Don't mix style and content commits. Never." - "You have to mark every style commit in the cvs commit message with »your prefered 'tag' for a style commit«." This would: - improve the readability/consistency of the code - makes your life not very difficult for this sorts of commits Just my 0.02 EUR, Alexander. -- There's no place like ~ http://www.Leidinger.net Alexander @ Leidinger.net GPG fingerprint = 7423 F3E6 3A7E B334 A9CC B10A 1F5F 130A A638 6E7E -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
