[...]
So I'm back to square 1, how can I go from AIFC to MP3? I have no real
experience with sound file formats and I really just want to write a front
end which uses tools written by people who know a lot more than me such as
lame :) Any tips are appreciated.
There's one really simple solution
Just thought I'd say my thoughts on the different parameter setting function
proposals we've had so far...
Individual functions for each parameter:
Pros:
- None. ;)
Cons:
- Litters the API with "thousands" of functions.
- If the parameter's type changes, the API has to change.
- If a
IIRC, if you use varargs then the compiler can't detect if the supplied
parameters
are of wrong type. Example :
[...]
The compiler won't notice that the parameter is of wrong type
and when the function will try to extract an int from the stack,
it will get garbage.
This is indeed true, and
o main.c can't hold lame_global_flags, change lame_init() to allocate and
return a pointer to lame_global_flags.
o Move lame_global_flags out of lame.h, it should never be accessed
externally.
I think we have to keep the old interface, since several applications
use it. So
and parsing gets abit more messy...
How ?
[...]
This is how it looks now, better than using va_arg() at each case imho...
void lame_set_int(lame_global_flags *gfp, lame_param_tag tag1, ...)
{
va_list ap;
int param; /* (varargs promotes integrals to int) */
va_start(ap, tag1);
This is how it looks now, better than using va_arg() at each case imho...
Why is it better ?
You wasted an additional variable and gained ( maybe ) some code space
by not doing a function call ( or maybe it is a macro , probably
platform dependant ) every time.
It's usually a (rather messy)
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. ;)
"Keep It Simple, Stupid".
[...]
Right, well, I believe that's exactly what it is now. ;)
- CISC
--
MP3 ENCODER mailing list (
This way there is no need to parse any strings, we don't pass
any pointers, the setup routine would just be a big switch/case.
This is basically the way TagItems work when passed on stack, in fact, that
combined with another identical function that does float we're pretty much
set.
Why do we need float at this point ??
Because several of the parsed arguments are floats?
ie. frequencies could be passed in Hertz as ints,
was just something to think about now while we
change the API anyway
Yes, but no reason not to have the possibility there. ;)
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
[...]
This way there is no need to parse any strings, we don't pass
any pointers, the setup routine would just be a big switch/case.
This is basically the way TagItems work when passed on stack, in fact, that
combined with another identical function that does float we're pretty much
set.
-
Why not something like:
lame_set_float(char *variable_name, float val);
lame_set_int(char *variable_name, int val);
Hey, gr8, idea, and maybe another with void*?
But this brings up another question: The code is going to do a lot of
parsing, and it looks like each variable will require several
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
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
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?)
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);
1) use commandline like strings to setup LAME's encoding engine
handle = lame_get_handle();
The fix is to do what Frank suggests: go to a data-encapsulted
type interface, where every parameter must be set via
a function. We would need to write about 100 functions
along the lines of: lame_set_input_samplerate().
A much better (and tidier) solution is to have one function that you can
I just made a new TAKEHIRO_IEEE754_HACK more ANSI C compliant.
I think we can make it default for Intel architecture.
This seems to work fine for PPC now (giving a speedboost of 10-15%), but
68k
still doesn't work (tons of reservoir errors),
IIRC, 68k doesn't use IEEE754 format at all -
I just conformed all this-is-included-defines (f.ex. UTIL_H_INCLUDED) to the
'project_file_name' style (f.ex. LAME_UTIL_H), this gives a good unique name
that shouldn't clash with any other defines (internal or system) already
existing...
I know it might seem rash touching so many files at once,
Reading Roel's initial statement, and all the replies, I'd like to comment
a little on this matter myself...
Yes, Roel was abit rash, but more than just a little justified imho. Don't
deny that quite a few of you were overpraising Vorbis long before it actually
was much to praise .. sure, it's a
#include "sndfile.h"
should be added to version.c on or around line 25, sf_get_lib_version is
undefined otherwise. Of course it only makes a difference if you use
libsndfile, but it caused me a problem.
Actually, I just fixed that, and the correct solution is to include
get_audio.h which in turn
Right, just committed a bunch of (quick and ugly) fixes to mpglib so it should
once again compile without spewing errors .. it's probably still completely
broken though, I hadn't time to test.
Someone should take some time going over mpglib and clean it up abit (Frank,
since you broke it, why
:: I run gcc 2.95.(3) and SAS/C (the latter is usually much more helpful on
:: warnings, and still much more forgiving on "errors")...
Can you add g++ for testing?
Or also some other C++ compiler?
Or use gcc at monday/wednesday and friday and g++ at the rest?
I have no incentive to use C++ at
I hope you guys correct all the errors. Please make sure that no new bugs
show up on the next beta release! If it's very much "broken" I think it'll be
best to start again with a previous alpha, one before someone broke it. Thank
you all who are working hard on making LAME such a great encoder!
Are you sure about that? The Layer2 decoding code doesn't compile for
me, and when I try to decode it says something about bug!!?? or
something like that, every file I try to decode does it (mp3, I disabled
layer1 and layer2 for now just so it would compile).
Ah, yes, I hadn't come that
:: Please check that your code compiles and works ok before checking it in
:: to the CVS ...
::
That doesn't help fully to solve the problem. Compiler and runtime libs are
different. So the check can only be done for one (or two) compilers.
Still, it's not fun when certain files fail to
Why add version 2 tags at all? Version 1 tags are virtually useless
within streaming audio (since they don't appear until the end of the
stream), so version 2 tag support is essential for that type of
application.
Not really. Take a look at my streaming MP3 station on Live365 at
This is a bug in the tables - that first line should be a 0 3
instead of 0 2. I have just fixed this, but it should have very
little effect on the output.
Ok, nice that we found that one then. ;))
And I dont think this could cause any crashes though. Can you
try adding a check in that loop
Did you try to increase the stack size? LAME 3.8x allocates local stack
space for the GTK variables even if you don't use GTK (some #ifdef are
gone) and this might lead to your problems. I've set the stack size of
512 kB and LAME works rock steady on my PPC Mac...
Hmm... that's something that
For some reason the latest versions of lame have crashed on my system when
running on PPC processor. The same code compiled for m68k processor
doesn't crash. I think the problem is probably memory access at invalid
address, but because of the system design, on m68k it luckily doesn't seem
to
Right, just committed a fix for a silly little bug which prevented mp3input
to work together with libsndfile...
I also noted that the --decode feature doesn't care about endianess, thus
ending up with a big endian wav (read; garbage. ;) ) on big endian machines.
Couldn't think up a quick fix
Ok, someone just broke something... ;)
..just tried the latest CVS stuff, and with Takehiro's IEEE hack weird stuff
happen with -h switch; not only is 72 bytes missing in the final file, but
the end gets trashed .. if I examine the file under a hexeditor, I can see
that several frames at the end
"LAME --resample 8 -b 8 input output" (MPEG2.5)
- Notice how everything is garbled.
just add a "--noshort -mm" here
The sample I tested with was already mono .. and if --noshort is needed in
MPEG2.5, why isn't it default?
there is no need for --noshort in general with MPEG2.5,
but this
Just thought I'd note that MPEG 2.5 is more or less broken at lower bitrates,
and that the filters seem screwy at low frequencies...
Try the following: (preferably with a 8kHz sample)
"LAME --resample 8 -b 8 input output" (MPEG2.5)
- Notice how everything is garbled.
"LAME --resample 16 -b 8
This feature is not default because it is deeply depending on IEEE754
floating point calculation and there're some computers NOT compatible
to IEEE754. (but it is so rare :p)
What exactly does the IEEE754 consist of, and what part does your hack
exploit? ;)
I am interested in the result of this
The binaries runs fine, and "make test" result is OK, too. but
the speed is slower than the no hacked version *sigh*
S It's faster here, but as mentioned of very poor quality. :/
BTW, is it the same result, with or without -h option ?
-h gives a much better mp3, but there's
[...]
As Gaby pointed out, it says the "decoder is not requires to support..."
which doesnt say they are invalid MP3 files :-)
Hey, btw, I just tested free-format with mpega.library and AmigaAMP's internal
decoder (FhG licensed), and both failed miserably. :/
- CISC
--
MP3 ENCODER mailing
This feature is not default because it is deeply depending on IEEE754
floating point calculation and there're some computers NOT compatible
to IEEE754. (but it is so rare :p)
When trying this hack the results got extremely noisy and of very poor
quality. This was on 68k, I've been unable to test
I just committed a NOPOW define to CVS which when enabled will replace
certain pow() combinations with optimized variants .. this gives an average
of 20% speedincrease on my machines (68k PPC), might be more or less on
yours, try it out... ;)
It made no difference on my pentium II.
Ok, it
S I just committed a NOPOW define to CVS which when enabled will
S replace certain pow() combinations with optimized variants ..
S this gives an average of 20% speedincrease on my machines (68k
S PPC), might be more or less on yours, try it out... ;)
Why don't you use table :)
Included is a quick patch to allow you to encode from 8bit files (wav/8svx
etc) when using libsndfile...
Oh, btw, how about automatic resampling when the input samplerate doesn't
match any of the allowed mpeg samplerates? ;)
I just applied the patch. Good idea about the resampling.
..it's
Included is a quick patch to allow you to encode from 8bit files (wav/8svx etc)
when using libsndfile...
Oh, btw, how about automatic resampling when the input samplerate doesn't match
any of the allowed mpeg samplerates? ;)
*** get_audio.c Tue Nov 16 21:43:30 1999
--- get_audio.c.new Sun
+ if (bitwidth==8) for (; samples_read 0; sample_buffer[samples_read] =
sample_buffer[samples_read--] * 256);
Whoops, that should ofcos be "samples_read = 0;"... :P
- CISC
--
MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Sorry I ever mentioned that __buffsize thing, it's a SAS/C specific feature,
and shouldn't be in LAME .. if Amiga-porters like to use it, I suggest they
go to http://csc.smsu.edu/~strauser/audio.html fetch the source available
there, and look at my amiga_version.c which automatically generates an
Something is wrong again, as I now am experiencing random crashes again, this
has been long gone, but somewhere around 3.30-3.50 it has been reintroduced. :(
I'm not sure, but I believe the previous problem was due to buffer overflow or
some dodgy memory allocation .. if anyone could check this
check this new patch containing new MDCT/subband filtering and FFT.
This patch can be applied to both of the original LAME 3.37beta(3.50stable)
and LAME3.37 with my yesterday Huffman coding patch.
Check mdct_sub in your newmdct.c...
void mdct_sub(
short *w0, short *w1,
double
is there a buffer option in Lame?
I need larger IO bufs.
Heh, as a matter of fact, I've just started a little discussion about that. ;)
If you are getting LAME from The Amiga Alternative Audio Page, the next
version there will probably have a bigger static buffer even if there haven't
been an
Kimmo Mustonen: Much code cleanup and Amiga updates
Hummm, any chance of telling me which changes he did?
I'd be very interested. ;)
Why's that? Well, not all my patches were included, but some of them were
Because I'm doing a semi-official port of LAME for Amiga... ;)
Check out The
Oh, btw, I've been hinted by one of my (LAME port) users that putting f.ex;
extern int __buffsize=10;
now what kind of importable, dubious hack is _this_?!!!
It's no hack, it's pure ANSI .. it's the reference buffer value for
input/output.
- CISC
--
MP3 ENCODER mailing list (
Concerning the file IO buffering discussed earlier, I'd suggest a scheme
somewhat resembling the following so as to scalably buffer at a rate that is
actually considering what amount of data we input/output.
Using setvbuf() we set buffers thusly;
Input: (samplerate * 2) * number_of_channels
Concerning the file IO buffering discussed earlier, I'd suggest a scheme
somewhat resembling the following so as to scalably buffer at a rate that is
actually considering what amount of data we input/output.
Using setvbuf() we set buffers thusly;
Hummm, ofcos, when reading up on how setvbuf()
Kimmo Mustonen: Much code cleanup and Amiga updates
Hummm, any chance of telling me which changes he did?
I'd be very interested. ;)
More stdin fixes: For some reason, forward fseek()'s would fail when
used on pipes even though it is okay with redirection from "". So I
There's a few problems in 3.34 that needs to be fixed... ;)
1. In get_audio.c the new wav/aiff routines presume that u_short etc are
pre-typedef'ed without even including sys/types.h.
2. In l3bitstream.c line 90 the following is done;
if ( frameResults == NULL )
{
frameResults =
..just noticed something weird with the timestatus that seems to occur when
encoding MPEG2-layer3...
It seems to report being twice as fast as it really is, this also seems to
only occur on stereo samples, so might it be that it adds both channels into
the timeline instead of treating them as
There seems to be something weird about how LAME encodes audio here when I
compare output from 68k and PPC versions of the program...
The MP3's differ quite a lot in normal mode, but not so much in -f mode, this
is however not an audible difference afaich, and comparing the decoded output
again
Ok, first off, a lot of functions are left empty with no prototype
declared, like f.ex. "void lame_init()", instead of doing it properly like
"void lame_init(void)" .. doing this will eliminate about half of the
compiler warnings (and also declaring prototypes in the appropriate .h
file)...
In get_audio.c at line 369 (and 210) "if ((".." (samples_read = 0))" ..
what is the purpose of this, as samples_read is a unsigned long, and thus
can never be less than zero?!
This should probably be considered a bug, since samples_read is supposed
to be able to handle a -1 return value. I
57 matches
Mail list logo
