I know that the --alt-preset encoding varies in speed depending on the type of music, but I encountered a sort of bizarre track. On track 2 on disc 1 of Nine Inch Nails' The Fragile, it starts out encoding at around 4x with --alt-preset standard (my average encoding speeds are around 3.5-4.5x), but a little bit into the track it drops immensely to around 0.2-0.4x encoding and continues at that speed for the rest of the track (and the number of 320kbps frames goes up significantly). I've encoded other "difficult to encode" music before, and goes to 320kbps frames, but doesn't slow down *that* much. It's not really a problem (I don't hear any problems in the mp3s, but then again my ears aren't that good), just sort of curious what's would cause this.

I'm no LAME developer, but I do remember from the LAME site and this forum that LAME will go through loops in the code to determine the amount of masking needed for the frame (if I understand right), and on complex and distorted music, which NIN is, it may have to "run the gauntlet" and iterate the whole loop in order to find the proper masking or whatever....

Delirium:

With the --alt-preset switches, much more than any other LAME setting, encoding times may be slowed down significantly during encoding certain aspects of a signal. These usually happen on harsh transients or impulses. Given the nature of NIN's music, it'd be likely that you'd run across some samples which are heavy with these signals. The situation you just described is probably one of those cases.

What johnicon described is sort of correct, LAME uses something called a quantization loop to determine how to pick the "best degredation" of the sound while encoding. What is happening is that on certain signals, --alt-preset switches to a much more aggressive (and much slower) method for achieving this. However, the quality is significantly higher because of this.

At any rate, a slowdown on the order of which you described should be fairly rare, especially on most non-electronic music.

Thanks for the explanation; makes sense to me. Looking back at the part where the slowdown occured in Winamp's little spectrum view it seems nearly the entire frequency range is at close to 100% volume for that part (there's two or three loud distorted guitars with an undistorted piano and some drums), which would seem to explain it. Though that occurs later in the song too and doesn't have that problem...there's something that sounds like it might be some sort of a mid-frequency sawtooth wave (or perhaps intentionally produced clipping? I'm not good at describing these sorts of things) layered over the part causing the slowdowns, so I'm assuming that's what the encoder doesn't like. FWIW oggenc slows down on this part too (though not as much), which is kind of unusual, since oggenc usually encodes pretty steadily at 4.9x for me.

This sounds suspiciously like the problem I've been having...after reading this post I made some tests using some Native American solo flute music. Encoding the same track twice using the same preset yielded two wildly different encode speeds (.37x v.s. 3.99x)with apparantly identical output files. It appears Lame isn't consistantly being allocated cpu time.

Actually, what was described earlier was related to documented behavior of the --alt-presets, in that certain situations result in extra time being required for encoding (extra rounds through the quantization loops are performed to keep noise lower than normal). This is perfectly normal and should result in similar speed (and slowdowns) on every encode.



From this and the earlier comment about such a drastic speed difference, I'd have to say this must be a problem specific to your system. There should be no LAME specific problem which is causing this. I've never experienced this problem, and I don't know anyone else who has. Perhaps you have something running in the background which is randomly using a large amount of cpu usage.

If you continue to have this problem perhaps you can give us more information on your system and what exactly you are encoding, maybe you can even provide a sample.