MAD 0.11.4b is now available.
Highlights include:
- Free format bitrate discovery is now working.
- There is now a Sun/NeXT 8-bit mu-law audio file output module.
- The OSS module now supports 32-bit output if also supported by your sound card and the version of OSS on your system.
- The output sample frequency match requirement has been relaxed. (Thanks to Dominic for suggesting a fix.)
- An endian assumption problem in audio_sun.c is fixed. (Thanks to Simon Burge for discovering this.)
- Some changes affecting SSO have been implemented, courtesy of Nicolas Pitre.
- A small patch to imdct_l_arm.S for a.out compatibility has been applied, courtesy of Simon Burge.
As a result of Nicolas's SSO changes, SSO now produces fully compliant, not limited accuracy, output. The trick was to do some extra rounding and shifting at compile-time, instead of shifting-only at run-time.
SSO is also faster now as a result, even slightly faster than the default configuration for ARM, so it can be enabled with --enable-speed now on all architectures.
Get the new version here:
ftp://ftp.mars.org/pub/mpeg/
Cheers, -rob
gcc -Wall -m486 -g -O -DHAVE_CONFIG_H -DFPM_INTEL -c -o fixed.o fixed.c
Even with --enable-speed, -O is the most used for Intels. Why is this?
On Tue, 26 Sep 2000, Sean 'Shaleh' Perry wrote:
gcc -Wall -m486 -g -O -DHAVE_CONFIG_H -DFPM_INTEL -c -o fixed.o fixed.c
Even with --enable-speed, -O is the most used for Intels. Why is this?
Because the C code is already carefully written with the operation flow for the best possible performances (loops were unrolled by hand only where it should be, etc). When -O2 (or hier) is used, gcc tries to be smarter than it should and actually produces worse output than with -O. This isn't generally true for many programs but it is for this particular application.
Nicolas
On 27-Sep-2000 Nicolas Pitre wrote:
On Tue, 26 Sep 2000, Sean 'Shaleh' Perry wrote:
gcc -Wall -m486 -g -O -DHAVE_CONFIG_H -DFPM_INTEL -c -o fixed.o fixed.c
Even with --enable-speed, -O is the most used for Intels. Why is this?
Because the C code is already carefully written with the operation flow for the best possible performances (loops were unrolled by hand only where it should be, etc). When -O2 (or hier) is used, gcc tries to be smarter than it should and actually produces worse output than with -O. This isn't generally true for many programs but it is for this particular application.
that makes sense, the use of m486 however actually causes worse performance on Pentium II's and higher I was told. I this true? perhaps the -m<arch> should be left off? Or at least made optional.
"Sean 'Shaleh' Perry" shaleh@via.net wrote:
that makes sense, the use of m486 however actually causes worse performance on Pentium II's and higher I was told. I this true? perhaps the -m<arch> should be left off? Or at least made optional.
Can anyone confirm this (perhaps by trying it with and without)?
-rob
-
Nicolas Pitre -
Rob Leslie -
Sean 'Shaleh' Perry