I don't know why this limit exists on PowerPC machines, though, both
Metroworks CodeWarrior and MPW (Free C/C++ Development environment by Apple)
have this limit. Known by reports on other Japanese mailing list, MPW has
critial bug obtaining large stack more than 32K. (We can compile, but
Hello, Lionel.
on 99.11.9 6:18 PM, Lionel Bonnet at [EMAIL PROTECTED] wrote:
The 32K limit doesn't really exists on PowerPC : in each application memory
zone, you have the stack zone and the heap zone.There is a default stack
zone(32 K)but if you want to increase it, you must change the
I know, of course, stack meaning, though, this is not such a problem, I
think. We can easily increase stack size with project settings - target -
PPC target - stack size (default 64K) in CW.
I wrote following test code, but could not compile. The line,
char chunk[64*1024L];
is
On Mon, 8 Nov 1999, Bill Eldridge wrote:
I was reading in one source that you can
1) convert MP L3 to MP L2 in the digital
domain without going analog
2) that MP L2 (l3?) gain cross-fades can be
done in digital domain by adjusting sub-band
parameters.
Anyone have more info on how this
Regarding the 32K size limit on local variables, the reason dates back to
the days of the 68K Macs. In a local routine, variables on the stack are
accessed as a 16 bit offset from a register, usually A6 (as opposed to A5
for global and "static" variables). They could be positively or
What kind of compiler would have a 32k limit for data on the stack???
The Amiga seemed to have this problem, but you could set some option
to increase the limit.
I don't know why this limit exists on PowerPC machines, though, both
Metroworks CodeWarrior and MPW (Free C/C++ Development
I am trying to figure out where in the code the mp3 data is outputted
frame by frame so that I can add an extra header to the frames so that
lame can interface with windows media player.
i looked in empty_buffer and I figured that at the fwrites: tmpbuf was one
frame of mp3 data being
From: Sigbjørn Skjæret [EMAIL PROTECTED]
Ah, I believe I just discovered why this happens. ;)
if ( frameResults == NULL )
{
frameResults = (BF_FrameResults*) calloc( 1, sizeof(BF_FrameData) );
assert( frameData );
}
See something odd? ;)
When I replaced BF_FrameData and
So minor, but
The new -B feature text says miximum instead of maximum.
Thanks for adding the feature Mark, and thanks for the reply concerning VBR
improvement.
mark stephens
--
MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
From: "Sigbjxrn Skjfret" [EMAIL PROTECTED]
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
From: Kali Griffin [EMAIL PROTECTED]
I am trying to figure out where in the code the mp3 data is outputted
frame by frame so that I can add an extra header to the frames so that
lame can interface with windows media player.
windows media player really wont accept a standard mp3 file???
11 matches
Mail list logo
