I'm going to break with tradition here, and post a review in this forum that's not a review of the Empeg Car itself. Since traffic in this thread is relatively light, I thought I'd take a chance and see if everyone would tolerate software reviews here, too.

Rjlov posted an alternate version of the Empeg kernel which adjusts the volume of tracks in real time. I was unable to try this out until version 11a of the kernel. But now, after a brief bout with MIME type errors corrupting the download (hey, Rjlov, zip that file on the server so others don't have the same error I did), I was able to run it this morning.

The purpose of the software is to change the volume of the tracks as you listen to them, so that the quiet bits are turned up louder. It's also intended to make the quieter songs in your collection fall closer into line with the louder ones. It's essentially a real-time normalizer. It sort of works like a dynamic compressor, although it's got some differences that make it sound slightly different (and better) than a compressor would.

I have to say, it's a success. It does exactly what it's supposed to do: It jockeys the volume of the tracks for you so you can hear the quiet bits better.

It's a little disconcerting to hear it slowly increasing the volume on the fade-out of certain notes, especially ones where you know the next bit's going to be really loud. At first, you get scared that the loud part will be way too loud. But it's coded so that the loud part won't clip- it has an emergency volume reduction part in the code. So once you get used to it, it's cool. It does what you would do in that situation (turn it back down when the loud part comes on), it just does it instantaneously for you at exactly the right moment.

I've only tried it with rock music so far. Since Rush is my favorite band, I've tested it on a few of their songs which I know have loud/soft/loud sections, and it works well in that format. The intro to "La Villa Strangiato", the "Discovery" and "Oracle" sections of "2112", the intro to "A Farewell to Kings", all work well. I haven't tried it yet with classical music, which I believe stands to benefit the most from this feature. Maybe it's time for me to find a good recording of "Bolero"...

I've also not listened to it in the car yet. I've only listened through headphones sitting here at the computer. If necessary, I'll add to this thread with updated information after I've had a chance to try it out in the car.

Although it works well, there's still some rough spots. First of all, it needs some read-ahead capability to reduce the "pumping" that can happen on certain songs. For instance, the "Soliloquy" section of "2112" has some pauses between the guitar notes where the volume of the waterfall gets pumped up unnaturally only to be cut down again when the guitar plays again.

Also, some work needs to be done on how it handles long fade-outs. It seems to drop suddenly from "amplified" to "zero" during a long fade-out. I know this was to compensate for it amplifying the track's noise floor unnecessarily, but perhaps there's a way to have it fade down instead of jump down suddenly?

Even with those minor problems, it still seems to work really well and I intend to use it on an upcoming road trip. We'll see how it does!

At the current time, it's just a proof-of-concept, and all the adjustment values are hard coded. What this really needs is integration with the player software, with the ability to turn it on and off from the menu, and editable parameters. Mostly, integration with the player software would allow it to do better read-ahead prediction and sound more natural.

I don't know if the Empeg guys have looked at this software yet. Guys? Have you? You should. I think this is something worth polishing up and officially including with the Empeg.

___________
Tony Fabris

It sounds brilliant. The Empeg guys should get it in there!

Calvin

Here's a follow-up:

Tried it out in the car, works great. Timing is odd on the intro to "Sledgehammer" though.

One idea that crossed my mind. Dunno if it'll work or not until you actually try it. But if there were a way to have it increase the volume logarithmically instead of linearly, it might sound more natural. For example, when there's a really quiet part, it steadily increases the volume at a fixed rate towards some specific target. If that increase were quick at the beginning, but slowed down its increase-rate as it got louder, it might not pump as badly but still deliver the desired result. Do you follow me? This might solve the "pumping" issue without needing too much read-ahead logic.

Another thing I noticed. Song fade-outs are interesting with this kernel because you get to hear most of the details of the fade-out at almost full volume. It's almost like the song doesn't fade out at all. There's the aforementioned problem where it simply "cuts" when it hits its noise-floor threshold, but once that's solved, fade-outs will sound cool. I like that because there are often interesting things to hear during long fade-outs if you listen closely.

___________
Tony Fabris

Yeah, I was never particularly happy with its treatment of the Sledgehammer intro.

It currently operates on a fixed proportional change per unit time. I think it's about 3db increase, and 6db decrease per second at the moment.

It linearly scales the current volume from between 0 and 1 to between about 0.1 and 1. That means that if you have input volumes of 0.01 and 0.001, these will both be scaled (given enough time for the gradual increase to finish doing its stuff) to very close to 0.1 output value. I have been thinking of how to do it differently.

Here's one idea:
Currently, the silence detection threshold is at whatever input value gives a desired output multiplier of 128. As it's scaling to around 0.1 for a minimum output value, then that means "silence" is anything smaller than 0.001. If we then attempt to maintain the ratios between the scaled outputs, then 1 => 1, 0.1 -> 0.5, 0.01 -> 0.24, 0.001 -> 0.1.
Basically, in this case, output_volume = exp(ln(input_volume) / 3)

The only problem with this is, does anyone have any (hopefully fairly fast) fixed point routines for ln and exp?

Actually, I only call this once per 4608 byte block, so perhaps they don't need to be that fast. I might try and roll my own approximations.

Richard.

The only problem with this is, does anyone have any (hopefully fairly fast) fixed point routines for ln and exp?

Talk to the Fractint guys. They're experts at doing floating-point operations with integer math. Incidentally, when one of the Empeg guys complained that the Vorbis format required floating-point to get its job done, that was the first thing I thought of. If you're willing to have a limit to the number of decimal points in your precision, you can do a lot of very fast floating-point math with integer operations. (Don't ask me how, though, it's all greek to me, ask the Fractint guys.)

___________
Tony Fabris

Given that Hugo has pointed out the ridiculously low loading of the CPU (even during full tilt whizz-bang action operation), I am surprised that there has apparently been no thought of porting across a decent floating point library to get around the interger math issue.

Mind you though, Toby's graphics don't suffer without it, and he's contributing to the empeg's CPU load factor!

One of the few remaining Mk1 owners... #00015

The player already has an FP emulator (contributed to the SA distribution by Corel) but it's far too slow for something as intensive as audio decompression.

The idea behind having 70% free CPU time is not to blow it all on a CODEC unless we REALLY have to. In this case I don't think it's worthwhile.

Rob

In this case I don't think it's worthwhile.

By "this case" I hope you mean Vorbis, not Rjlov's volume adjustment. I can't imagine that anything he's doing with the volume would affect the CPU load perceptibly at all.

___________
Tony Fabris

Damn, I'm getting my threads mixed up.

Yes - Vorbis Bad, Rjlov Good

Rob

Another follow-up:

Rjlov just e-mailed me another kernel which seems to have fixed the bug where song endings got cut off. I dunno if he's posted it at his web site yet. I'm going to be taking some long drives over the next couple days, and I'm confident enough in this kernel to commit to using it during these drives. I'll report back in a few days if I learn anything new about its behavior.

And to clarify for anyone else interested in trying it:

- Currently it's only for version 11a of the empeg. Mark2 owners don't get to use it yet, just us early adopters.

- You need either the Linux or Win32 kernel downloader utilities to squirt it into your Empeg. The command line to upload it is the same as you'd use to put one of those personalized-logo kernels in place: download.exe zimage_filename 10000



___________
Tony Fabris

Hiya.

There's now yet another beta11a kernel available. This one has the out = exp(log(in) / 3) behaviour discussed earlier. It alleviates the "fade-out" problem (not necessarily solved, though). I think I'm fairly happy with this one so far.

You can get it at http://home.eric.net.au/~rjlov/compress.html.

I put it in a zip file this time. Also included is the kernel source patch, so if people want they can stick it in their own custom kernels. Actually, I guess I'm obliged by the GPL to make the source patch available.

Richard.

Hey, with that post I graduated to Journeyman!

I strongly suspect that the volume adjustment would be easier to do, have a longer lookahead, and use fewer CPU cycles if it were integrated into the player software. Plus, of course, some UI to adjust the parameters would be very funky (or even get values from tags in the database).

Still, I'm loving it even in its current primitive form!

Richard.

I'm going to be taking some long drives over the next couple days, and I'm confident enough in this kernel to commit to using it during these drives. I'll report back in a few days if I learn anything new about its behavior.

Empeg + voladj kernel + Pacific Coast Highway 1 + windows down = heaven.

___________
Tony Fabris

I just installed version 3 of that kernel, thanks. It's working fine, although it doesn't completely solve the long-fade-out-cutoff problem for me. It doesn't seem to cut off the ends of songs unless they have long fade-outs. I'm pretty sure all it's doing is dropping the volume from "amplified" to "normal" suddenly when the quiet bit drops below the noise floor threshold. If that was just a sloped volume decrease instead of a cutoff, it would sound fine. I dunno how you'd handle that in the code, though.

As I was driving and listening to the music through this kernel, a thought occured to me:

The main reason we want to amplify the quiet bits, is because we want to hear them above the noise floor of the car's interior environment, right? When there's no ambient noise, we'd prefer not to have the volume adjuster kernel pumping away at the tracks. Sounds like a perfect application for the mic input to me. Make the volume adjuster parameters get more agressive as the ambient noise level goes up, and back off on the parameters as the ambient noise drops to zero.

This differs from the concept of "speed sensitive volume" (already discussed elsewhere) in the following way: If you're driving on the freeway at a stead speed, an ordinary speed-sensitive-volume control would leave unit at a fixed volume, with the quiet bits still being too quiet compared to the loud bits. My version would continue to behave like the voladj kernel, dynamically adjusting the individual musical passages to keep them above the noise floor, it would just do it more agressively when the car cabin environment is louder.

Anyway, that's just a pie-in-the-sky idea, but I thought I'd share it.

I put it in a zip file this time.

That worked great and solved my download problems.

Also included is the kernel source patch, so if people want they can stick it in their own custom kernels.

Speaking of which, it would be cool if you and Bobo could get together and offer a combination kernel: Volume adjustment plus custom logo. Actually, Bobo could just take your included source code and patch his own if he was up to it. Bobo, are you reading this?

___________
Tony Fabris

> Sounds like a perfect application for the mic input to me. Make the volume adjuster parameters get more agressive as the ambient noise level goes up, and back off on the parameters as the ambient noise drops to zero.

Yep, that's kinda the idea. Originally I'd envisaged that it would scale all music between max volume and the noise floor. The intention was always that as you relaxed the parameters, the limit would be no distortion, so when you're stationary and just listening to music, you don't suffer. This was true with the linear scaling, I have a feeling that it's not 100% true with the logarithmic scaling because of limitations of the log/exp implementation. I'll work on that.

It would be really cool to get the value for that noise floor from a mike.

Richard.

I like your idea.

I'm all for it.

Calvin

I'm new to this board. I am on the wait list for a MkII (#15154), and can't wait. I was reading this thread and was thinking about this very idea when I got to this message.

I have an S2000 Roadster which doesn't have speed-sensitive volume unlike many convertibles. I had heard that the Empeg had a mic input and may eventually have voice command. But if it could be used for "ambient noise-sensing" and auto- adjust the volume, that would be AWESOME! It would be much better than plain speed-sensitive.

Damn, now I'm REALLY jonesing for my number to get called for my MkII! Hopefully, by the time I get mine (probably Sept-Oct, fingers-crossed), beta versions of this feature will be available!

Hello.

Feel free to download another volume adjusting kernel. This one is otherwise the same as 12b. There have been a couple of bug fixes, and a couple of improvements. Thanks tfabris for pointing some of these out! Now, you can decide what you want the minimum volume to be, and what input volume you want to map to that minimum volume, and it will figure out an appropriate scaling factor. At least, that's what it's supposed to do.

Actually, I wonder if it would work as a volume expander? I don't see why not. It wouldn't be very useful, of course, but I might just try that for a bit of fun.

You can get it (as usual) at http://home.eric.net.au/~rjlov/compress.html.

Richard.

If this is the same one you mailed to me last night (Beta 12b, try 2), it's been working great for me all day and I haven't had a problem with it. The fade-outs now sound perfect, there are no pops, the volume doesn't seem to pump unnaturally (at least not to my ears). It also supports the custom logos fine. Very impressive work!

Now, you can decide what you want the minimum volume to be, and what input volume you want to map to that minimum volume, and it will figure out an appropriate scaling factor. At least, that's what it's supposed to do.

I assume you mean that there's a hook in the code to adjust this if it ever gets integrated with the UI. You can't really set this stuff right now without re-compiling, can you? Or is it reading values from config.ini?

My only desire now is to be able to edit the parameters from the UI. I think that there are times I would want it to be more agressive than the defaults that are coded into it.

___________
Tony Fabris

I assume you mean that there's a hook in the code to adjust this if it ever gets integrated with the UI. You can't really set this stuff right now without re-compiling, can you?

That's correct. I was sort of thinking of making a file in /proc where you could set the parameters. That would be cool in that I would learn how to do it, but it would appear to have limited utility. You still need some program or interface to set the values at run time, which doesn't exist. Actually, didn't someone try an experiment with replacing the renaming the player executable, and calling something else "player"? I guess you could just have a shell script which writes appropriate values into /proc, and then execs the player. Hmmm.

Richard.