Re: [MP3 ENCODER] mpglib related routines (Re: modularization)
On Mon, Oct 02, 2000 at 04:11:57AM -0600, Mark Taylor wrote:
>
> 4. LAME should be converted to C++ or Java. C just is not up to
> the task of distinguishing between 30 different types of integers.
>
* Good C programs should use the following identifier for variable names:
new, delete, operator, public, private, protected, class, template,
restricted, ...
* Variable initialization should be skiped via goto or switch
* The expression sizeof('A') should be used as synomym of the size of an
integer
* variables types and initializers should never match fully.
* Prototype functions with ellipses with:
int printf ();
* never cast mallocs/callocs().
* use identically identifier for name spaces which are separated in C
and merged in C++ (struct, unions, typedefs).
--
Frank Klemm
--
MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] mpglib related routines (Re: modularization)
> > 2. I dont think declaring the sample rate as 'long double' is enough. We > need to add a portable, object oriented arbritrary precision floating > point library to LAME. The sample rate should be a default of > 128 digits, but the user can increase this with suitable > options. > Mathematican: Arbitrary precission is not enough. Physist: Planck time is around 10^-42 s, age of universe is around 10^+18 s, so 60 decimal digits are good enough. non C Programmer: Current CPUs are supporting long double (being 64 or 80 bit) in hardware, so why we aren't use this. Assembler Programmer: How large are the floating point registers? Is there any trick to store two numbers to increase speed? No? Video technican: Films are at most around 4 hours, humans can detect time differences down to 20 ms, so we need something around 6 decimal digits. Markedroid: Reduce precission as long as noone complains. Advanced Markedroid: Reduce precission as long as noone charges you. Professional Markedroid: Reduce precission as long as income increases. C Programmer: Why we are not using a 'int', if we need more precission, then we can store ms or mHz in ints. Also µs, ms, cs and s/HZ are possible (see POSIX API). C++ Programmer: We need a class ... Ada programmers: Don't we have a generic type to store time intervals? COBOL programmer: Sample frequencies are between 0 and 9 Hz, right? FORTRAN programmer: It isn't an index, so I use a REAL. Rivest: Can we assume that all sample frequencies can be exactly described by a/b with a and b being two finite integral numbers with gcm (a,b) := 1 ... Haskell programmer: Do we need numbers? You can describe all by sets. or: There is really no computation until you want to remove the WAV files from hard disk. Perl: What are types? > 4. LAME should be converted to C++ or Java. C just is not up to > the task of distinguishing between 30 different types of integers. > Current C (C89 + POSIX) has something around 18 integer types. C99 + POSIX something around 90 integer types. May be the ISO committee is stupid, may be they have recognized some problems of the C language. C89 + POSIX ~~~ char signed char unsigned char short unsigned short long unsigned long int unsigned int size_t ssize_t off_t ptrdiff_t wchar_t ptr_t clock_t time_t C99 + POSIX ~~~ char signed char unsigned char short unsigned short long unsigned long int unsigned int size_t ssize_t off_t off64_t fpos_t fpos64_t ptrdiff_t wchar_t wint_t ptr_t clock_t time_t int8_t int16_t int32_t int64_t int128_t uint8_t uint16_t uint32_t uint64_t uint128_t int_least8_t int_least16_t int_least32_t int_least64_t int_least128_t uint_least8_t uint_least16_t uint_least32_t uint_least64_t uint_least128_t int_fast8_t int_fast16_t int_fast32_t int_fast64_t int_fast128_t int_fast16_t int_fast32_t int_fast64_t int_fast128_t uint_fast8_t uint_fast16_t uint_fast32_t uint_fast64_t uint_fast128_t bool ... Also note: float_t and double_t And there are also a lot of Unix types out there (having currently fixed sizes): pid_t, dev_t, ino_t, fsid_t, gid_t, uid_t, mode_t, umode_t, nlink_t, ... -- Frank Klemm -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] mpglib related routines (Re: modularization)
:: :: 3. Creating a dozen or so odd types, all synonymous with 'int' :: is a great idea. But I saw a few 'int's left. I think :: we need to replace these with more new types. :: When you were a physicist, you were a cgs advocate and a SI enemy, right? -- Mit freundlichen Grüßen Frank Klemm background for not involved: cgs (stands for centimeter, gram, second) sets several elemental constants to 1 ( c=1, µ=1, k=1, kb=1) and uses only (floating point) numbers for all physical quantities. You can write all thing shorter and faster, and often you have no idea what you are talk about. eMail | [EMAIL PROTECTED] home: [EMAIL PROTECTED] phone | +49 (3641) 64-2721home: +49 (3641) 390545 sMail | R.-Breitscheid-Str. 43, 07747 Jena, Germany -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] mpglib related routines (Re: modularization)
>This is a good idea. Some comments (Frank: not all of these are serious:-) I am serious :) > 5. All developers should be required to take 200 hours of UML training > before working on any more code. 6. Learn more about CVS, especially about making your own branch. --- [EMAIL PROTECTED] // may the source be with you! -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] mpglib related routines (Re: modularization)
> What about the proposal to design and discuss a well designed lame API now > without implementation? AFAICS this takes at least 3 months, if you want to > have a durable and neat API, Mark don't want to change the API until summer > 2001. May be should use this time to design all the structures are needed > and the lame.h file needed. This interface should be designed in a way, so > >* no arbitrary constants are in it >* also Layer I, Layer II and AAC can added to this interface >* also multiple channels are possible >* feed count be int16, int32, float, double >* Support of huge arrays (open file, memmap, run encoder once, save result) >* solving 'Gap' problem >* solving compatibility problem with LAME 3.xx interface > > I propose a file 'NewAPI.h', were all this is written down (prototypes and > rationale). This is better than only discussing and later forgetting the > results. > This is a good idea. Some comments (Frank: not all of these are serious:-) 1. file I/O has been removed from the library, so we only have to deal with encoding buffers. 2. I dont think declaring the sample rate as 'long double' is enough. We need to add a portable, object oriented arbritrary precision floating point library to LAME. The sample rate should be a default of 128 digits, but the user can increase this with suitable options. 3. Creating a dozen or so odd types, all synonymous with 'int' is a great idea. But I saw a few 'int's left. I think we need to replace these with more new types. 4. LAME should be converted to C++ or Java. C just is not up to the task of distinguishing between 30 different types of integers. 5. All developers should be required to take 200 hours of UML training before working on any more code. Mark -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] mpglib related routines (Re: modularization)
On Sun, Oct 01, 2000 at 09:10:19PM +0200, Robert Hegemann wrote:
>
> So for backward compatibility we should make a wrapper library
> with the old interface (as much as possible) and mark this as
> old and outdated, to give clients the possibility for smooth
> migration to the new API.
>
>
> old clientnew clients
> ||
> v|
> wrapper lib |
> ||
> ++-
> | ||
> v vv
> lame-enc-lib lame-dec-lib lame-hdr-lib
>
>
> lame-enc-lib:
> - lame's encoding engine
> - maybe with Xing's VBR header stuff if it must be
>
> lame-dec-lib
> - lame's wrapper to the mpg123 library
>
> lame-hdr-lib
> - wave header
> - Xing header
> - ID3 stuff
>
> wrapper lib
> - the old libmp3lame and interface
>
What about the proposal to design and discuss a well designed lame API now
without implementation? AFAICS this takes at least 3 months, if you want to
have a durable and neat API, Mark don't want to change the API until summer
2001. May be should use this time to design all the structures are needed
and the lame.h file needed. This interface should be designed in a way, so
* no arbitrary constants are in it
* also Layer I, Layer II and AAC can added to this interface
* also multiple channels are possible
* feed count be int16, int32, float, double
* Support of huge arrays (open file, memmap, run encoder once, save result)
* solving 'Gap' problem
* solving compatibility problem with LAME 3.xx interface
I propose a file 'NewAPI.h', were all this is written down (prototypes and
rationale). This is better than only discussing and later forgetting the
results.
/*
* All Bitstream Data is stored in a bitbuffer_t structure. So you
* - only have to pass one argument
* - functions have the chance to increase the buffer if necessary
* - you don't need the return value to return the size of the MP3 data,
* so you can return other things (error codes or other stuff)
* - correctness of the bitbuffer parameter can be checked by the C Compiler
* - all functions have the same structure
*
typedef struct {
void* data;// data buffer, allocated via malloc ()
const size_t size;// maximal size of the data buffer
size_tlen; // valid octets stored in this structure
} bitbuffer_t
/*
* The lame API only sees very little of the internal structure of
* _IO_LAME. Only if compiled with BUILD_LAME_LIB all elements are
* visible (and writable).
*/
typedef void (*fnptr) (...);
typedef struct {
#ifdef BUILD_LAME_LIB
const fnptr* virtual_function_table;
int128struct_ID;
int init_state;
...
#else /* BUILD_LAME_LIB */
const fnptr* virtual_function_table;
const int128 struct_ID;
const int init_state;
const char__internal_data__ [32000];
#endif /* BUILD_LAME_LIB */
} _IO_LAME;
typedef int errorcode_t;
bitbuffer_t open_bitbuffer ( size_t size = 16384 );
int close_bitbuffer ( bitbuffer_t* buffer );
int set_FILE_binary ( FILE* fp );
LAME*lame_open ( void );
int lame_close ( LAME* lp );
/* Nice would be if this fucntions returns the exact input frequency. But this is only
possible if
the output frequency is available */
long double lame_set_input_samplefreq ( LAME* lp, long double freq = 44100.l );
long double lame_set_output_samplefreq ( LAME* lp, long double freq = 44100.l );
int lame_set_number_of_channels ( LAME* lp, int front = 2, int rear = 0, int
dual = 0, int docu = 0 );
int lame_set_min_bitrate( LAME* lp, int minbitrate = 112000 );
int lame_set_max_bitrate( LAME* lp, int maxbitrate = 32 );
int lame_set_minmax_bitrate ( LAME* lp, int minbitrate = 112000,
maxbitrate = 32 );
int lame_set_cbr_bitrate( LAME* lp, int minbitrate = 128000 );
real lame_set_cwlimit( LAME* lp, real freq = 8871.68 );
const char* lame_version( LAME* lp );
real lame_set_mask_to_noise_ratio( LAME* lp, real ratio = 0. );
lame_mode_t lame_set_bitrate_mode ( LAME* lp, lame_mode_t mode = lame_cbr );
real lame_set_fullscale_level( LAME* lp, real fullscale = 32768. );
int lame_set_coding_quality ( LAME* lp, int quality = 50 ); // 0 worst,
50 default, 100 best
int64lame_read_coded_pcmsamples ( LAME* lp );
errorcode_t lame_encode_buffer_short (
LAME* lp,
bitbuffer_t* buffer,
size_tpcmdata_len,
const short* channel1,
... );
errorcode_t lame_encode_buffer_interleaved_short (
LAME* lp,
b
Re: [MP3 ENCODER] mpglib related routines (Re: modularization)
Hi Robert, This just seems like a lot of work for no real gain since all 4 libraries are samll and closely related. To build LAME we would need a ./configure setup which builds 4 different libraries. so I guess I just dont see any reason to seperate them. Special applications, like embeded encoding, will be using static libraries anyway, so they can just compile a lightweight version of libmp3lame.a. Mark > > > So for backward compatibility we should make a wrapper library > with the old interface (as much as possible) and mark this as > old and outdated, to give clients the possibility for smooth > migration to the new API. > > > old clientnew clients > || > v| > wrapper lib | > || > ++- > | || > v vv > lame-enc-lib lame-dec-lib lame-hdr-lib > > > lame-enc-lib: > - lame's encoding engine > - maybe with Xing's VBR header stuff if it must be > > lame-dec-lib > - lame's wrapper to the mpg123 library > > lame-hdr-lib > - wave header > - Xing header > - ID3 stuff > > > wrapper lib > - the old libmp3lame and interface > > > > Ciao Robert > > > > -- > MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ ) > -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] mpglib related routines (Re: modularization)
Mark Taylor schrieb am Son, 01 Okt 2000: > > > > >I think the mp3 encoding library should do what it is > > >supposed to do, encode pcm samples into mp3 frames. > > > > BTW, Robert and everyone, how should we treat with mpglib and lame_mp3_XX > > routines in frontend/get_audio.c and amiga_mpega.c ? > > > > I think these routine should be another library, and the library name > > should not be lame_XXX > > > > any ideas ? > > --- > > Takehiro TOMINAGA // may the source be with you! > > -- > > We have to at least try and break the old, "frozen" interface > as little as possible. There are many applications which > use this interface (to the static library). > > There are some issues related to this if the library becomes a popular > shared library. However, there is only 1 application which uses LAME > as a shared library, and it uses a built in feature of Linux to check > the version number before running. So right now the shared library > issues are moot. It is more important to get the static library > working than it is to solve all issues related to the shared library. > > So I want to have encoding, decoding, id3tags and vbrtags in > libmp3lame.a, and only one include file, lame.h. Once this is all > working, then we can start on the new function call interface to LAME. > When that is done, we can then schedule the old, public struct > interface for removal, but it should stay around for at least > a year or so. > > > Mark So for backward compatibility we should make a wrapper library with the old interface (as much as possible) and mark this as old and outdated, to give clients the possibility for smooth migration to the new API. old clientnew clients || v| wrapper lib | || ++- | || v vv lame-enc-lib lame-dec-lib lame-hdr-lib lame-enc-lib: - lame's encoding engine - maybe with Xing's VBR header stuff if it must be lame-dec-lib - lame's wrapper to the mpg123 library lame-hdr-lib - wave header - Xing header - ID3 stuff wrapper lib - the old libmp3lame and interface Ciao Robert -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] mpglib related routines (Re: modularization)
> > >I think the mp3 encoding library should do what it is > >supposed to do, encode pcm samples into mp3 frames. > > BTW, Robert and everyone, how should we treat with mpglib and lame_mp3_XX > routines in frontend/get_audio.c and amiga_mpega.c ? > > I think these routine should be another library, and the library name > should not be lame_XXX > > any ideas ? > --- > Takehiro TOMINAGA // may the source be with you! > -- We have to at least try and break the old, "frozen" interface as little as possible. There are many applications which use this interface (to the static library). There are some issues related to this if the library becomes a popular shared library. However, there is only 1 application which uses LAME as a shared library, and it uses a built in feature of Linux to check the version number before running. So right now the shared library issues are moot. It is more important to get the static library working than it is to solve all issues related to the shared library. So I want to have encoding, decoding, id3tags and vbrtags in libmp3lame.a, and only one include file, lame.h. Once this is all working, then we can start on the new function call interface to LAME. When that is done, we can then schedule the old, public struct interface for removal, but it should stay around for at least a year or so. Mark -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
[MP3 ENCODER] mpglib related routines (Re: modularization)
>I think the mp3 encoding library should do what it is >supposed to do, encode pcm samples into mp3 frames. BTW, Robert and everyone, how should we treat with mpglib and lame_mp3_XX routines in frontend/get_audio.c and amiga_mpega.c ? I think these routine should be another library, and the library name should not be lame_XXX any ideas ? --- Takehiro TOMINAGA // may the source be with you! -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
