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/ )
