Re: [MP3 ENCODER] Voice mode
Hi all On 15-Oct-99 Greg Maxwell wrote: Are you aware you can use lame for image compression? :) compression.. Check out http://linuxpower.cx/~greg/mp3crap/ for some examples of this kind of perversion.. This is so perverse it's actually neat. :) Anyone tried the reverse? Image compression on sound files? later mike (I vote for a switch to the LGPL) -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] Voice mode
Duh.. I see, M/S is define with addition/subtraction not multiplication. So, is there a downloadably doc that describes intensity mode, are decoders a good source of info? There is a few lines (only a few) about it in the iso docs. If you don't have them yet, they are available on mp3tech.org Unfortunately, it's unlikely that I'll have the time to work on this. As it does not seems to be much difficult to make (at least it's easier than m/s stereo), perhaps Patrick could allow some of his students to work on this. I can't do it during my own student project, as mine must be about image processing or image synthesis. Are you aware you can use lame for image compression? :) First create an greyscale image ((576*x)*n, or (1152*x)*n for best results) save it as ascii ppm. Cut off the header. Use sox to go from 8bit unsigned to a 16 bit mono wav file set at 44100. Encode, reverse.. Looks preety good, perhaps if you do some kind of transform on the input first to make it less 'transiant' (some kind of reversiable convolution) you might get better compression then jpg (it's not too far as is). Kinda gives you respect for how tough audio compression is VS image compression.. Check out http://linuxpower.cx/~greg/mp3crap/ for some examples of this kind of perversion.. (Why did I do this? I was hoping nasty artifacts might be more easily found in a picture rather then listening to a sample) That's strange... I'll have a look at it Regards, Gabriel Bouvigne - France [EMAIL PROTECTED] icq: 12138873 MP3' Tech: www.mp3tech.org -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] toolame 01d (fwd)
The opther point is that you can't trust your compiler using its maximum optimization level. It sometimes produces weired results, and you always have to check the accuracy when, as an example, you're using egcs with -O9. Horsecocky. If EGCS is producing bogus code, that's a bug in your C, in EGCS or in your headers. I'd wager in the C. In the past nearly six years of developing Ogg, I've found one gcc bug, no egcs bugs, two Linux libc header bugs and one libc bug. Each one was exactly that-- A bug, not evil voodoo. There are plenty of ways to write bad C that will seem OK in -O0, and then break under optimization because it violates ANSI. I'm probably arguing semantics (I suspect we actually agree), but I wanted to pipe up and make the point clear. Monty -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] toolame 01d (fwd)
On Fri, 15 Oct 1999, Gabriel Bouvigne wrote: With modern compilers, you don't generally need to bother with replacing for (i = 0; i len; ++i) sum += array[i]; with for (p = array, endp = array + len; p endp; ++p) sum += *p; Any compiler worth its salt will do it for you in a microsecond - or might not, if it thinks it will be less efficient; performing the strength reduction yourself restricts the compiler's options. The following loop is faster than array, both on hppa processors using g++, pentium, celeron and pIII using both egcs and msvc++: for (i=len, p=(array+i); i--; ) sum+=*--p; Descending loops with pointer use have always shown to be faster than arrays. I use them a lot in image processing. I think this is true (for a single pointer loop, for multiple/too many pointers I think Takehiro is right, see earlier postings; pointers can no longer be alloc'ed to registers, so memory is needed and this slows down things? however we could/should test again on multiple architectures??); Anyway, I got this idea from a recent book discussing all sorts of optims, and how (good) recent compilers work, I can look up the ref if you want it; I was also looking into this kind of thing to change the lame code all over the place (i.e. inside the subbandfiltering). (Part of) Reason for speed up I believe is you can save/replace the 'i' "cmp value + bne/beq" assembler with only "bne/beq" (branch equal or not). Never checked actual gcc output assembler and speed myself; could/should be done for (too)lame ? Just another thing I'll add to my optim/sb-filter list I guess :( ;) regards, Patrick. -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
RE: [MP3 ENCODER] toolame 01d (fwd)
From: Gabriel Bouvigne [mailto:[EMAIL PROTECTED]] The following loop is faster than array, both on hppa processors using g++, pentium, celeron and pIII using both egcs and msvc++: for (i=len, p=(array+i); i--; ) sum+=*--p; Descending loops with pointer use have always shown to be faster than arrays. I use them a lot in image processing. Indexing in reverse order is a separate issue. When I compare your version with for (i = len; i--;) sum += array[i]; under both MSVC and gcc 2.95/i386, the array version is actually slightly faster. -- Mat. -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] toolame 01d (fwd)
Patrick De Smet wrote:
I was also looking into this kind of thing to change the lame code all
over the place (i.e. inside the subbandfiltering).
(Part of) Reason for speed up I believe is you can save/replace the 'i'
"cmp value + bne/beq" assembler with only "bne/beq" (branch equal or not).
Never checked actual gcc output assembler and speed myself; could/should
be done for (too)lame ? Just another thing I'll add to my optim/sb-filter
list I guess :( ;)
regards,
Patrick.
Yeah, I was noticiing some places with things like:
for (i=0;i248;i++) {
if (i64) {
(do x)
else (i64) {
(do y)
and was wondering how much:
for (i=0;i64;i++) {
do x
for (i=64;i248;i++) {
do y
would speed things up, and whether the compiler would
be clever enough to catch it. (It's easier to read the
first way, but introduces 248 unneeded comparisons).
I'll look at the new cleaned up code now.
--
MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
--
Bill Eldridge
Radio Free Asia
[EMAIL PROTECTED]
--
MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] 3.34 beta bug?
On Thu, 14 Oct 1999, Mark Taylor wrote: Encoding with ./lame -mj -b 96 -h -g applaud.wav ap2.mp3 on RedHat 6.1 The re-synth on frame 16 granule 1 looks seriously wrong. Thanks for finding that. it is a bug in frame analyzer code and shouldn't effect the output. Mark Yes, it sounded okay. -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] Voice mode
On Fri, 15 Oct 1999 [EMAIL PROTECTED] wrote: Hi all On 15-Oct-99 Greg Maxwell wrote: Are you aware you can use lame for image compression? :) compression.. Check out http://linuxpower.cx/~greg/mp3crap/ for some examples of this kind of perversion.. This is so perverse it's actually neat. :) Anyone tried the reverse? Image compression on sound files? I did a long time ago, it doesn't work too well (using jpg at least) mostly because it only works on 8-bit and 2d quant doesn't go well with sound. later mike (I vote for a switch to the LGPL) -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] LAME license, once again...
At 12:25 PM 10/15/99 +0200, Gerhard Wesp wrote: On Thu, Oct 14, 1999 at 06:27:01PM +0200, Nils Faerber wrote: First of all since all parts of Lame are GPL the usage of header files included ofr use of Lame as any sort of DLL for other programs will force let me cite the gpl: ``If identifiable sections of that work are not derived from the Program, and can be reasonably considered independent and separate works in themselves, then this License, and its terms, do not apply to those sections when you distribute them as separate works.'' so i'd advise your german company to just distribute lame as a ``separate work'' together with the download software, which should arguably be independent of the encoder. separate does _not_ mean that lame has to be on a different cd! to encode, just call lame from a shell script or via system(3). should be trivial, eh? This might be hard to do, if they are implementing Lame in a DSP/embedded application. Don't know if this is the case for the German company though.. How does the mp3 license work? Can you just get a licence and distribute Lame with full source? /jp (Who thinks it would be great if Lame became more used, esp. if BladeEnc(LGPL:ed) is the other alternative ;)) -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
[MP3 ENCODER] psycho models, optimizations and toolame01e
Hi all, I found an interesting paper on psychomodel 1 which may contain some useable ideas: (it also comes with C source) ftp://ftp.icsi.berkeley.edu/pub/real/kyrill/PsychoMpegOne.tar.Z They discuss using formula for values instead of tables and thus (this is the good bit) they can apply the psycho model to *any* bitrate, not just the 48/44.1/32 rates. They don't discuss speed aspects though, and I'd hazard a guess that it's quite slow. Source code is there for all to see. I've found on my p166 box, that loop order in a for() statement does affect speed. I've mostly seen that a for(i=999; i0;i--) is faster than if we started with 1 and counted up. And yes, there are still plenty of loops within toolame which need looking at. Toolame01e is at www.cryogen.com/mikecheng Main change is adding the FHT-based fft() from the LAME code. Which speeds it up a significant amount. II_f_f_t() now calls fht() rather than doing its own fft. Did other cleanup and changed default settings (192kbps, .mp2 filename) Added a downmix to mono mode. Added Patrick's scale_factor_calc If you've got an idea, send it in. If you've got a patch, mail it to me. (caveat: try to keep individual patches simple. ie small incremental changes :) Time to code Babylon5 Track 1 (236 seconds) @ 128kbps toolame psy1226seconds psy2284 nopsy 91 nopsy mono 55 CDEX-iso220 Iomega recordit 60 later mike -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] toolame 01d (fwd)
On Fri, 15 Oct 1999 10:59:39 +0100 (WEST), Patrick De Smet wrote: Descending loops with pointer use have always shown to be faster than arrays. I use them a lot in image processing. Descending loops allow the compiler to replace the loop index comparison with a BNZ (branch if not zero) instruction. Most loops I use in my uC assembly projects are this way. More out of convience than speed though. I think this is true (for a single pointer loop, for multiple/too many pointers I think Takehiro is right, see earlier postings; pointers can no longer be alloc'ed to registers, so memory is needed and this When did the pointer in a register go away? Are you telling me that the register keyword dosen't do anything in modern compilers? Forgive me if this is old hat. Most of my work is in the embedded world of 8-bit uCs. Anyway, I got this idea from a recent book discussing all sorts of optims, and how (good) recent compilers work, I can look up the ref if you want it; Yes please send me the ref offlist. In fact if we can probally take this discussion off list unless other are interested in it. -- Richard A. Smith Bitworks, Inc. [EMAIL PROTECTED] 501.521.3908 Sr. Design Engineerhttp://www.bitworks.com -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] toolame 01d (fwd)
Horsecocky. If EGCS is producing bogus code, that's a bug in your C, in EGCS or in your headers. I'd wager in the C. In the past nearly six years of developing Ogg, I've found one gcc bug, no egcs bugs, two Linux libc header bugs and one libc bug. Each one was exactly that-- A bug, not evil voodoo. There are plenty of ways to write bad C that will seem OK in -O0, and then break under optimization because it violates ANSI. I'm probably arguing semantics (I suspect we actually agree), but I wanted to pipe up and make the point clear. Monty Compilers sometimes have bugs, and gcc and egcs have some (even some in common). That's why there are some new release, no? I'm talking about real bugs. Hopefully, sometimes the compiler is smart enough to see that it has some bugs: "internal compiler error, please submit a bug report". You've never seen it? It's very rare, but sometimes happens... (I only saw 1 bug with -O9 under gcc, and 1 internal compiler error under both gcc and egcs during the past years) Regards, Gabriel Bouvigne - France [EMAIL PROTECTED] icq: 12138873 MP3' Tech: www.mp3tech.org -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] toolame 01d (fwd)
When did the pointer in a register go away? Are you telling me that the register keyword dosen't do anything in modern compilers? Forgive me if this is old hat. Most of my work is in the embedded world of 8-bit uCs. In modern compilers, the register keyword is an indication. The compiler try to use it, but it can decide to ignore it. Yes please send me the ref offlist. In fact if we can probally take this discussion off list unless other are interested in it. I'm also interested in. Gabriel Bouvigne - France [EMAIL PROTECTED] icq: 12138873 MP3' Tech: www.mp3tech.org -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] toolame 01d (fwd)
Compilers sometimes have bugs, and gcc and egcs have some (even some in common). That's why there are some new release, no? I'm talking about real bugs. OK. I was fairly sure we were actually agreeing, and we were. BTW, in case LAME folks don't know about it yet (this is a major bug and it's just becoming widely known): The glibc bug I mentioned is just now becoming widely known (we just discovered it over on the Vorbis development project). All versions of linux glibc for x86 (and therefore x87) to date (I have not looked at other platforms, I expect the bug is there too) use hardwired hand-rolled assembly calls in the math inlines for common math functions like log(), sin(), etc... EGCS does not have control over these calls and nothing inspects the asm contents until the assembly stage. Because FP stack usage mapping happens earlier, any of these calls that pushes onto the FP stack will overflow it if EGCS has already used all eight stack entries. Until glibc is widely fixed, -D__NO_MATH_INLINES is necessary for working FP code. (gcc 2.8+ and egcs are affected. Previous versions are not affected because glibc explicity excludes the inlined headers for gcc 2.7.x and earlier) Hopefully, sometimes the compiler is smart enough to see that it has some bugs: "internal compiler error, please submit a bug report". You've never seen it? It's very rare, but sometimes happens... (I only saw 1 bug with -O9 under gcc, I'll guess it was the 2.7 loop unrolling bug where the compiler initialized the wrong part of the resulting code? That's the one I found. (BTW, my idiosyncratic number is -O20. I use it for everything including Vorbis and the kernels on my boxen :-) Monty -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
