Unoffical empeg BBS

Quick Links: Empeg FAQ | Software | RioCar.Org | Hijack | jEmplode | emphatic
Repairs: Repairs | Addons: Eutronix | Cases

Page 1 of 2 1 2 >
Topic Options
#4044 - 02/05/2000 01:04 Normalization, EASY
Nils
member

Registered: 09/06/1999
Posts: 197
Loc: Germany
Hi !

Okay, another comment regarding normalization:
Let us just presume that we all have many songs that are *NOT* normalized, maybe because we got them from someone else, or maybe because we did not use Software that can do normalization when ripping. Whatever reason there might be, but i guess many of us face this problem.

So here is one easy approach to solve the "different volume levels" problem, that naturally goes along with playing such songs on the empeg:

Please empeg programmers do the following:
When playing a song the first time on the empeg, just track down the highest reached amplitude in the song, to get its highest reached volume level.
( Of course the user must play the COMPLETE song, no skipping or aborting )

So in the end you have a number ( let it be -5 db in our example ), please remember this number by storing it in the info file ( where the empeg also finds artist/songname and so on, basically the extracted id3 tag ).

NEXT time the empeg plays the song, it can detect that the highest vol level has already been measured and can simply adjust the internal volume accordingly.

So if the current general volume setting is -20 db and the info for the file says -5 db ten use -20 + 5 = -15 db as the output volume.

VOILA !

So that would mean, whenever i heard a song 1 time, all following accesses to that song will play it normalized.

SIMPLE, isn't it ?!

No hassle, no trouble, not difficult to implement ( give me your player source and 10 minutes ........ aehem and 2 weeks to study the code before, but you do know it, so for you its just that 10 minutes :)

Please do so, or tell me where i am wrong.

Nils


Top
#4045 - 02/05/2000 07:50 Re: Normalization, EASY [Re: Nils]
tfabris
carpal tunnel

Registered: 20/12/1999
Posts: 30696
Loc: Seattle, WA
This has already been suggested. However, it still won't solve the problem of songs which sound like they are at different volume levels.

I used to think as you do: That normalization was the key to making all the songs sound evenly loud. After playing around with normalizing some "quiet" albums, I discovered that this is not the case. Different songs are mixed with different amounts of dynamic compression. The more dynamically compressed a song is, the louder it seems. It's like television commercials: They sound louder than the television shows. It's not because the TV shows don't hit the peak (in fact the TV shows and the commercials are both normalized to the same peaks), it's just that the commercials are dynamically compressed so that all of the sounds (even the quiet ones) are closer to that peak.

It is possible that an algorithm could be written which measures the overall loudness of a piece (not based on peaks alone), but such an algorithm would be complicated to write and it would take a lot of CPU time to churn on each file.

I still think that the Empeg or Emplode should allow the user to assign a "relative volume" parameter to the songs, but if you based that parameter on peaks alone, it wouldn't make much of a difference. It would take a lot of work to assign those values to your entire collection.

Tony Fabris
Empeg #144
_________________________
Tony Fabris

Top
#4046 - 02/05/2000 17:34 Re: Normalization, EASY [Re: tfabris]
rjlov
member

Registered: 16/12/1999
Posts: 188
Loc: Melbourne, Australia

If anyone's interested, my initial efforts at a proof-of-concept realtime volume adjuster have been moderately successful, and very promising. It's pretty easy to compensate for quiet passages, but you need some buffer to stop ugly clicks when the music suddenly gets loud. At the moment, I'm not doing any buffering at all, so basically no memory is required. My next step will be to try it with a very small buffer (probably the audio write size on the empeg) of read-ahead and see if I can eliminate the clicks completely. I don't see any reason why there should be a problem.

This is not really a compressor. It makes only slow adjustments to the volume (except where a sample would cause clipping at the current volume) at a rate of about 3db per second.

I'll let you know about the results of my next experiment.

Richard


Top
#4047 - 02/05/2000 19:41 Re: Normalization, EASY [Re: rjlov]
tfabris
carpal tunnel

Registered: 20/12/1999
Posts: 30696
Loc: Seattle, WA
Now that is insanely amazing and cool. You have our full attention. Let us know how it goes.

Tony Fabris
Empeg #144
_________________________
Tony Fabris

Top
#4048 - 03/05/2000 00:51 Re: Normalization, EASY [Re: Nils]
Henno
addict

Registered: 15/07/1999
Posts: 568
Loc: Meije, Netherlands
Nils, could you send me your e-mail address?
Henno
(henno.empeg@xs4all.nl)

Henno
# 00120
_________________________
Henno mk2 [orange]6 [/orange]nr 6

Top
#4049 - 03/05/2000 10:34 Re: Normalization, EASY [Re: Nils]
mcgrant
journeyman

Registered: 28/04/2000
Posts: 84
Loc: Menlo Park, CA USA
I think a technique like yours might work, but looking for the highest amplitude reached is not the right way to go, because it really won't give you an accurate idea of the "volume" of the song.

Here's an extreme example: consider a song that is quiet throughout, but has one single sample that sticks way up. Normalizing the song based on that one sample would still keep it too quiet. I think this is what Tony is referring to when he talks about dynamic range compression; it's a "peak to mean" ratio problem.

But with one simple change, I think your idea would work great. Instead of measuring the peak amplitude, measure the average power instead. In other words, square each sample's amplitude, add them up, and divide by the total number of samples. To translate that to a decibel measure, just take 10 * log10( value ). That's going to be a more accurate picture of the "volume level" of the song.

I've seen MP3 rippers that do this kind of normalization. But when they use it to modify the original MP3 file, the have to be careful not to introduce clipping. So they often will have a flag that prevents normalization if the peak amplitude exceeds, say, 95%.

With this little change I think your idea would work really well!

Michael


_________________________
Michael Grant 12GB Green 080000266

Top
#4050 - 03/05/2000 11:01 Re: Normalization, EASY [Re: mcgrant]
tfabris
carpal tunnel

Registered: 20/12/1999
Posts: 30696
Loc: Seattle, WA
I've seen MP3 rippers that do this kind of normalization. But when they use it to modify the original MP3 file, the have to be careful not to introduce clipping. So they often will have a flag that prevents normalization if the peak amplitude exceeds, say, 95%.

But all of the CD's I've checked already have a peak amplitude of at least 97 percent. Even the ones that are too quiet. CD's are already normalized when you get them. So you can't increase the volume of the source files significantly without clipping the peaks. If you're working on just the source files, the only solution is compression, which is tricky to get right.

A "relative volume" parameter for the playback hardware is a good solution (in fact, it's supported in the ID3v2 tag specification whenever Empeg gets around to implementing that spec), but you'd have to be careful there, too. For example, if you've tuned your system so that 0db on the Empeg is your maximum comfortable listening volume, then a quiet song with a +10 relative volume tag would clip at the player stage. It would be safer to insert negative values into the loud songs than to put positive values into the quiet songs.

Your idea for an algorithm which analyzes the song based on average volume level sounds like a good start, and such a program could be a great starting point for filling out the relative volume field in the ID3v2 tags. Although I think such an algorithm would be a bit more complex than what you describe.

Tony Fabris
Empeg #144
_________________________
Tony Fabris

Top
#4051 - 03/05/2000 16:00 Re: Normalization, EASY (long) [Re: tfabris]
rjlov
member

Registered: 16/12/1999
Posts: 188
Loc: Melbourne, Australia

Well, last night I completed phase two of my volume adjustment experiment, and once I ironed out some annoying bugs, I'd have to declare it a pretty much unqualified success.

It works like this:

Monitors the maximum sample magnitude in x sample blocks. It then calculates
a desired scaling factor based on this maximum sample. This calculation is a simple linear interpolation between a user specified minimum desired volume, expressed as a number between 0 and 1. The limit of the scaling factor as the minimum desired volume approaches 0 is 1. i.e. If you set minvol to 0, you don't get any distortion of any kind.

If the desired scaling factor differs from the current scaling factor, then multiply the current scaling factor by a number close to 1, so that it becomes closer to the desired scaling factor. This number (and the number of samples we take the maximum from) is what determines the speed at which we respond to volume changes in the music. I've found that setting them so that we get a maximum volume slew rate of about 3db per second is a good level.

That's the basic algorithm! It is basically a filter that requires no memory of previous samples, just the maximum value.

However, there is a problem that if we set minvol to 1, and our music volume is slowly increasing, we will get clipping because we can't respond to the increasing sample sizes until AFTER we have actually played them. To reduce this effect, I added a sort of "headroom" parameter into the desired scaling factor calculation. This means that we will always have room to play samples that are slightly bigger than the ones we have examined so far. This allows the slow volume adjustment to work in both the increasing and decreasing directions.

However, it can't handle the case where you have quiet music that suddenly gets loud. So, I added an emergency volume reducer. This is the bit which needs some sort of read-ahead buffer. It looks n samples into the future. If it finds any samples which would cause clipping it then changes the scaling factor (linearly at the moment, I couldn't be bothered doing it exponentially) from the current value so that by the time the big sample is ready to be played, the scaling factor is the desired scaling factor.

I found this to work reasonably well with a read-ahead buffer of 100 samples! I haven't tried it with a smaller buffer, I guess I should.

That's all I've done so far.

In summary, it listens to the music. If the music is too soft, it gradually turns up the volume. If the music is getting too loud, it gradually turns down the volume. However, it looks into the future, and if we would get clipping soon, then it very quickly turns the volume down so that we don't.

I've currently implemented this in perl, because it was easy to do. If any one wants a copy of the code, I'll mail a copy to Rob and ask him to put it on the developer site. I'm not proud of the code, as I have deliberately ignored many implementation issues in order to quickly prove the concept. The code is ugly, inconsistent, inflexible and slow (it reads one sample at a time, converts them into numbers in perl, and then works on them from there) but all of this could be easily fixed with a decent reimplementation in C. I haven't got time at the moment, though.

I've done only minimal testing so far. My test samples have been the first 30 seconds or so of Holst's Mars, and of Sledgehammer. I can never hear the quiet bits at the start of these tracks in the car. The results are pretty good. The only problem is that because of the slow volume change rate, it takes a few seconds to get to the desired volume, but I can live with that. I'd rather miss out on just the first few seconds of a quiet section than the whole thing.

All my testing at the moment has been done with the minimum desired volume set to 1. This means that it attempts to scale everything to maximum volume. In real life you would only use this value if your listening environment noise floor was essentially the same as your maximum volume. This is the most severe condition, and all the changes are less drastic with a smaller minvol. The way I envisage it, if it was ever implemented in the empeg, minvol could be set with a secondary volume control. You might leave your main volume (maximum volume) set to the same value all the time, but change minvol depending on the amount of background noise.

What do people think? I think it's a very simple algorithm, with very few resource requirements, that could make a big difference to the level of enjoyment.

Richard


Top
#4052 - 03/05/2000 16:42 Re: Normalization, EASY (long) [Re: rjlov]
tfabris
carpal tunnel

Registered: 20/12/1999
Posts: 30696
Loc: Seattle, WA
I've done only minimal testing so far. My test samples have been the first 30 seconds or so of Holst's Mars, and of Sledgehammer.

Heh, good examples. I remember when a friend of mine bought "So" just for that song. He cranked that flute intro because it was so quiet, and nearly lost his hearing and his speakers when the trumpets and bass came in.

Also be sure to make sure it works for fade-ins. For example, U2's "Wire" off of Unforgettable Fire, or Peter Gabriel's "The Rhythm of the Heat" from Security. Two other great examples I can think of quiet intros followed by loud songs are by Rush: "Show Don't Tell" from Presto, and "Animate" from Counterparts. "Animate" is simply Neil's voice quietly counting off the tempo, followed by a max-volume drumbeat.

This sounds really cool. I'm really interested in hearing something like this in action. Coolest long-term real-world test would be as a WinAmp plug-in.

One question: Isn't there some Prior Art on this sort of thing that you could look at? I've heard of TV sets that implement something like this...

Tony Fabris
Empeg #144
_________________________
Tony Fabris

Top
#4053 - 04/05/2000 00:12 Re: Normalization, EASY [Re: tfabris]
mcgrant
journeyman

Registered: 28/04/2000
Posts: 84
Loc: Menlo Park, CA USA
Your idea for an algorithm which analyzes the song based on average volume level sounds like a good start, and such a program could be a great starting point for filling out the relative volume field in the ID3v2 tags. Although I think such an algorithm would be a bit more complex than what you describe.

Why do you say this? Is it because you don't think that the average power gives a good measure of the subjective "volume level"? I mean, decibel figures are nothing but relative power differences, there's nothing subjective about those; so the formula I describe is quite precise in that respect.

However, you might be correct in saying that one +20dB song can sound louder or softer than another +20dB song. I'm not an audio engineer, just an engineer.

If you're working on just the source files, the only solution is compression, which is tricky to get right.

No argument here...




_________________________
Michael Grant 12GB Green 080000266

Top
#4054 - 04/05/2000 09:02 Re: Normalization, EASY [Re: mcgrant]
tfabris
carpal tunnel

Registered: 20/12/1999
Posts: 30696
Loc: Seattle, WA
Why do you say this? Is it because you don't think that the average power gives a good measure of the subjective "volume level"?

Yeah, that's what I meant. I'm sure that such algorithms have been written before, although I haven't yet tried poking around on the 'net to find anything in this vein. I'd be curious to see if anyone has written up any definitive white papers on the subject.

Tony Fabris
Empeg #144
_________________________
Tony Fabris

Top
#4055 - 04/05/2000 15:01 Re: Normalization, EASY (long) [Re: rjlov]
tanstaafl.
carpal tunnel

Registered: 08/07/1999
Posts: 5302
Loc: Ajijic, Mexico
Would a possible worst-case scenario be Ravel's "Bolero" with what amounts to a 15-minute long crescendo?

What adjustments would your algorithm make in this instance? If the entire piece were played at the same effective volume level (single flute intro as loud as the whole orchestra with brass section in the closing bars?) I'm afraid you would lose much of the effectiveness of the piece.

On the other hand, it would be nice to actually be able to hear that flute intro sometime when I am driving the car.... Same thing could be said for the trumpet intro in Prokofiev's "Lt. Kije Suite".

Reading threads like this one reinforces my appreciation for what a terrifically great group of people we have on this bbs! I wonder if it would be possible once the Mark II hordes begin their onslaught to require potential new bbs registrants to pass some sort of test to verify their technical acuity before being allowed to post to the board. What, elitist? Who? Me? ;-)

tanstaafl.

"There Ain't No Such Thing As A Free Lunch"
_________________________
"There Ain't No Such Thing As A Free Lunch"

Top
#4056 - 04/05/2000 16:22 Re: Normalization, EASY (long) [Re: tanstaafl.]
rob
carpal tunnel

Registered: 21/05/1999
Posts: 5315
Loc: Cambridge UK
> once the Mark II hordes begin their onslaught

A brief off-topic note..

We've no reason to think that the demographic of future empeg owners is going to differ very much from current trends - you guys just happened to get into the queue a bit faster!

Rob



Top
#4057 - 04/05/2000 19:03 Re: Normalization, EASY (long) [Re: rob]
tfabris
carpal tunnel

Registered: 20/12/1999
Posts: 30696
Loc: Seattle, WA
Yeah, but it's just the quantity thing. The bigger the basket of apples, the more bad ones you get. And Usenet proves how much louder the bad apples are than the rest of them.

(Am I stretching my metaphors too much?)

Tony Fabris
Empeg #144
_________________________
Tony Fabris

Top
#4058 - 04/05/2000 20:21 Re: Normalization, EASY (long) [Re: tanstaafl.]
rjlov
member

Registered: 16/12/1999
Posts: 188
Loc: Melbourne, Australia
tanstaafl wrote:
If the entire piece were played at the same effective volume level (single flute intro as loud as the whole orchestra with brass section in the closing bars?) I'm afraid you would lose much of the effectiveness of the piece.

That is (in my opinion) the beauty of the algorithm. It's intended to have a user configurable parameter, where you specify the minimum volume level you want to hear. All your dynamics still exist, but they aren't as pronounced. If your car is stopped, you set this parameter to 0, and then you get the full dynamic range (no distortion at all, actually). If you're driving around town, you might set it to 0.1 or 0.2. On the highway you might set it to 0.5. For a bit of a lark (just to see what it sounds like) you might set it to 1.0. However, rather than actually calculating these numbers by hand, I envisage that you have an upper limit volume control (the existing volume control) and a lower limit volume control. The empeg would then calculate the appropriate number between 0 and 1.

Update: I've rewritten my little program in C, and now I use 32 or 16 bit integers for everything, and now it is rather a lot faster than it used to be. The implementation also magically became a lot simpler once I started using a fixed length buffer. Hopefully by Monday I'll have it in a form that other people can try it out, and figure out if it's the sort of thing they'd like on their empeg. For a giggle, I tried setting the volume adjustment to 30db per second. I got many audible artifacts. 3db per second seems fairly acceptable.

Richard.


Top
#4059 - 05/05/2000 05:54 Re: Normalization, EASY (long) [Re: tfabris]
Lord Bleys
member

Registered: 30/12/1999
Posts: 143
(Am I stretching my metaphors too much?)

/lurk off
No, You're right on target."
/lurk on

-- Bleys

"If you would judge, understand." -- Seneca
_________________________
"If you would judge, understand." -- Seneca

Top
#4060 - 05/05/2000 09:32 Re: Normalization, EASY (long) [Re: rjlov]
tfabris
carpal tunnel

Registered: 20/12/1999
Posts: 30696
Loc: Seattle, WA
This sounds fantastic. I'm dying to hear it in action. Two questions:

1: I assume everything you're doing so far has been in Linux? Are you experienced enough with Windows coding to try it as a WinAmp plug-in?

2: Does it alter the bits of the wave data directly, or does it jockey the volume control on the player software?



Tony Fabris
Empeg #144
_________________________
Tony Fabris

Top
#4061 - 05/05/2000 19:53 Re: Normalization, EASY (long) [Re: rob]
tanstaafl.
carpal tunnel

Registered: 08/07/1999
Posts: 5302
Loc: Ajijic, Mexico
We've no reason to think that the demographic of future empeg owners is going to differ very much from current trends - you guys just happened to get into the queue a bit faster!

I dunno, Rob... think about the kind of person who would spend five to ten times the going price of a "normal" car stereo in order to have an untested, untried piece of delicate hardware from a company nobody had ever heard of to put in his car, running software (software! not a CD changer or something consumer-friendly) which in its earliest iterations might best be described as pre-beta. These are some REALLY special, technically astute people with an incredible willingness to share what they know! (Just ask Tony tfabris a question about Rush, and you'll learn more than you ever thought existed!) When the empeg becomes widely available and consumer friendly, the user base will change. Who was it that said, "The end result of making things foolproof is world filled with fools."?

When I think back over all the emails I have sent and received from literally dozens of participants on this bbs, and the thousands (yes, thousands!) of entertaining and informative posts I have read on this bbs... I would be hard pressed to find another bbs anywhere to even approach the quality of this one. Even if something should happen that I never get an empeg of my own (I'm #8741...) I've had a great time here on the 'board.

tanstaafl.



"There Ain't No Such Thing As A Free Lunch"
_________________________
"There Ain't No Such Thing As A Free Lunch"

Top
#4062 - 05/05/2000 22:35 Re: Normalization, EASY (long) [Re: tfabris]
rjlov
member

Registered: 16/12/1999
Posts: 188
Loc: Melbourne, Australia
Yes indeed, it has all been in linux. I don't even have a windows C compiler, so I can't really builda winamp plug-in. Mind you, the code is intended to be used by other code. It is a very simple API. If you have access to some plugin source, it ought to be trivial to make it use my code.

Basically, you initialise the thing with the blocksize (this must remain constant, but that's no problem on the empeg), db per second, minimum volume level and headroom.

Then you simply call two functions (voladj_check and voladj_scale) alternately on your raw data (16 bit samples). voladj_scale modifies the samples in place (which I think answers your second question).

There's a structure which holds all the long-lived data that gets passed back and forth, so if you wanted you could rig up some sort of mechanism to adjust it in real time. The code at the moment just sets up the parameters to start with and then leaves them alone.

The whole thing is especially designed to be as little effort as possible for the guys at empeg to integrate into the player. I've even been testing it on blocks of 4608 bytes. Presumably the data is already in blocks like this before it is written to the audio device. All they need to do is call a couple of functions on it before they do the write.

You can hopefully find the code at http://home.eric.net.au/~rjlov/compress.c.

You will have to compile it with the math libraries (use -lm with gcc). The floating point is only used in the initialisation. All the actual processing is done with fixed point numbers. By the way, this software will probably work best if your samples have initially been normalised to the maximum value.

It's currently written with the philosophy that clipping is bad, and must be avoided at all costs. That could be changed. It also would be pretty easy to change voladj_check to calculate a desired multiplier based on the average power, rather than the peak volume, as people have described in this thread.

This is my first attempt at fixed point non-integer arithmetic, so I've probably done things a bad way. If you have suggestions, feel free to tell me or make the improvements yourself.

Richard.



Top
#4063 - 06/05/2000 02:29 Re: Normalization, EASY (long) [Re: tanstaafl.]
Henno
addict

Registered: 15/07/1999
Posts: 568
Loc: Meije, Netherlands


and, Rob, don't forget that once you have thousands of customers filling this board you won't have the time to read the conversations, leave alone that you will be able to continue the type of personal customer support that we've grown accustomed too (and highly appreciate). I hope you guys find a method that will allow to keep up what you've been doing. You're an example 'par excellence' of 'e-customer relations'; can go into any book on e-commerce.

Henno
# 00120
_________________________
Henno mk2 [orange]6 [/orange]nr 6

Top
#4064 - 27/05/2000 22:29 Re: Normalization, EASY (update) [Re: rjlov]
rjlov
member

Registered: 16/12/1999
Posts: 188
Loc: Melbourne, Australia
Hi there

I have now compiled my volume adjustment code into a beta10 kernel. I've hard-coded the various parameters with what I consider to be reasonable values. It would be so cool to set these from tags in the database on a song-by-song basis. It appears to make a big difference for classical pieces with quiet sections. It also appears to work best if you have already normalised the peak values in your tracks, but it doesn't require this.

So, if anybody is still interested (the silence has been deafening since I posted my initial attempt at some source code, I don't know what this means) you can get a beta10 kernel by following the link at http://home.eric.net.au/~rjlov/compress.html. Please give it a try and tell me what you think.

Would people prefer a beta10a kernel?

Richard.


Top
#4065 - 28/05/2000 01:09 Re: Normalization, EASY (update) [Re: rjlov]
Henno
addict

Registered: 15/07/1999
Posts: 568
Loc: Meije, Netherlands
if anybody is still interested . . . .

Bet you, that we are interested!
Bet you that Empeg are following this too.
I just hope it works as well as it sounds

Lost my Emma / am awaiting Mark2, so I will not comment for a while.
Downloaded your kernel anyhow. Will follow comments closely and suggest that we start a new thread on this

Henno
ex 00120
_________________________
Henno mk2 [orange]6 [/orange]nr 6

Top
#4066 - 28/05/2000 12:13 Re: Normalization, EASY (update) [Re: rjlov]
tfabris
carpal tunnel

Registered: 20/12/1999
Posts: 30696
Loc: Seattle, WA
the silence has been deafening since I posted my initial attempt at some source code

Sorry about that, but I don't have a linux box to compile the code on, so I couldn't do anything with it. But now that you've posted something I can run on the Empeg (amazing-- I didn't know there was a way to get into that part of the player yet) I will start running it as soon as I can. I'm still at the convention this weekend and don't have my player with me, but I will download it first thing on Tuesday.

Would people prefer a beta10a kernel?

Yes, I would like a 10a version, but if you don't have one, I'll settle for 10. Something else to think about: There's a new version of the software coming out very soon (for all I know, it may be announced already, I haven't checked the general forum yet), and you might want to be prepared to compile one for that version, too, since it's got one-button-shuffle working (and some other features Hugo showed me that I'm going to report on when I get back from this weekend).

___________
Tony Fabris
_________________________
Tony Fabris

Top
#4067 - 29/05/2000 01:51 Re: Normalization, EASY (update) [Re: tfabris]
andy
carpal tunnel

Registered: 10/06/1999
Posts: 5692
Loc: Wivenhoe, Essex, UK
There's a new version of the software coming out very soon (for all I know, it may be announced already, I haven't checked the general forum yet), and you might want to be prepared to compile one for that version, too, since it's got one-button-shuffle working (and some other features Hugo showed me that I'm going to report on when I get back from this weekend).

According to the release notes beta11pre does not update the kernel, just the player software, so this shouldn't be neccessary.


__
Unit serial number 47 (was 330 in the queue)...
_________________________
Remind me to change my signature to something more interesting someday

Top
#4068 - 29/05/2000 15:50 Re: Normalization, EASY (update) [Re: tfabris]
rjlov
member

Registered: 16/12/1999
Posts: 188
Loc: Melbourne, Australia

Well, last night was the first time I've driven anywhere with my new kernel. I was listening to random tracks for about an hour, and in general I'm pretty happy with the result. I think I'm going to change the way it handles silence, though, because you get some objectionable effects every so often (it's running with no lookahead). At the moment it just maintains the previous multiplier level when it is silent. I think I'll make it so it gradually reduces the multiplier during silence.

The other thing I want to do is make it look further ahead. I've been having a look in empeg_audio.c and it seems the best way to force it in would be to have a separate desired multiplier setting for each audio_buf, and then just before setting up the DMA stuff, scale the current desired multiplier to the minimum of all the desired multipliers, and then call voladj_scale. The only problem I foresee with this is that it might take too long to do the scaling. It doesn't sound like the sort of thing you want to be doing in an interrupt handler.

Richard.



Top
#4069 - 08/07/2000 02:19 Re: Normalization, EASY (update) [Re: rjlov]
rjlov
member

Registered: 16/12/1999
Posts: 188
Loc: Melbourne, Australia
Hi there.

I've finally decided to upgrade past beta10. However, I didn't want to be without my volume compression. So, if people want it, there's now an 11a kernel available for download at this address. There's also a kernel patch, for those who like to build their own kernels.

If anybody downloaded my original version, this one is better, it seems to cause less yukky artifacts. Hurrah!

Richard.


Top
#4070 - 08/07/2000 10:10 Re: Normalization, EASY (update) [Re: rjlov]
tfabris
carpal tunnel

Registered: 20/12/1999
Posts: 30696
Loc: Seattle, WA
...there's now an 11a kernel available for download...

Cool, just downloaded it! I'm concerned about how to send it to the Empeg, though... do I use the same procedure that I use for Bobo's modified startup-logo kernels? i.e., "download zimage 10000"?

Of course, if this works, I lose my special bootup logo. Someday I'll get a linux partition going so I can compile these things together myself. :-)

___________
Tony Fabris
_________________________
Tony Fabris

Top
#4071 - 08/07/2000 10:31 Re: Normalization, EASY (update) [Re: tfabris]
tfabris
carpal tunnel

Registered: 20/12/1999
Posts: 30696
Loc: Seattle, WA
Well, when I do this:
download empeg-voladj.11a.zImage 10000

I get a non-bootable Empeg which gives me this out the serial port when I turn it on:
Clearing 8Mb of RAM...
Copying kernel...
Calling linux kernel...
(data abort vector)


Is it possible that the .zImage file is corrupt or something? Or am I doing it wrong? Maybe it's like the MIME type problem that Empeg had with the ".upgrade" files? If so, perhaps you should zip the file and offer the .ZIP for download?

___________
Tony Fabris
_________________________
Tony Fabris

Top
#4072 - 09/07/2000 15:59 Re: Normalization, EASY (update) [Re: tfabris]
rjlov
member

Registered: 16/12/1999
Posts: 188
Loc: Melbourne, Australia
> Well, when I do this:
> download empeg-voladj.11a.zImage 10000
> I get a non-bootable Empeg which gives me this out the serial port when I turn it on:

Zowee! Sorry about that, but it works fine for me. That's pretty much the command I use to send the kernel to the empeg. Also, it appears that I uploaded it to the web site correctly, because I just downloaded it again and compared the two files, and they were identical!

Does your kernel have the output of cksum like this?
1332374491 290020 downloads/empeg/empeg-voladj.11a.zImage
It should.

If anybody else has ideas I'd be interested. I presume you _were_ running beta11a before downloading the kernel. Next time I have the chance (I can't upload things to that web site while I'm at work) I'll do as you say and offer a zipped version as well.

Richard



Top
#4073 - 09/07/2000 22:17 Re: Normalization, EASY (update) [Re: rjlov]
tfabris
carpal tunnel

Registered: 20/12/1999
Posts: 30696
Loc: Seattle, WA
Well, I have no idea what its checksum is, since I'm not running linux and I don't have that option. The "download" command I used is the win32 command-line kernel downloader that Bobo supplied me to go with the bootup-picture kernel.

I'm guessing that my Netscape browser did the same thing to the .zimage file that it did to the .upgrade files because the MIME types weren't set.

Plea for everyone on the planet offering files to download for any reason: Zip the files (or Arj or Rar or whatever). Even if the zipping doesn't save any disk space or bandwidth. Reasons: 1. No MIME problems. 2. When you unzip them, that's a built-in integrity check. If it unzips successfully with no errors, you can be certain it's a good file.

This goes for your .upgrade files, too, Empeg guys.

___________
Tony Fabris
_________________________
Tony Fabris

Top
#4074 - 10/07/2000 00:44 Re: Normalization, EASY (update) [Re: tfabris]
rob
carpal tunnel

Registered: 21/05/1999
Posts: 5315
Loc: Cambridge UK
There's not really a problem with the .upgrade files, as we have control over the MIME settings of our own web site. There was only a problem initially because we forgot to add this type of file.

Rob



Top
#4075 - 10/07/2000 06:51 Re: Normalization, EASY (update) [Re: rjlov]
tfabris
carpal tunnel

Registered: 20/12/1999
Posts: 30696
Loc: Seattle, WA
Yeah, that turned out to be the problem: The file didn't download properly for me from the web site. Rjlov sent me the file via e-mail and it worked fine after installation.

I'm going to post a review of this software in the "reviews" section of the BBS. Perhaps pushing the envelope of the appropriate subject matter for that thread, but hey, I'm green now, so that must mean I can do what I want.

___________
Tony Fabris
_________________________
Tony Fabris

Top
#366781 - 24/05/2016 02:41 Re: Normalization, EASY (long) [Re: rjlov]
rjlov
member

Registered: 16/12/1999
Posts: 188
Loc: Melbourne, Australia

Originally Posted By: rjlov
It also would be pretty easy to change voladj_check to calculate a desired multiplier based on the average power,


Turns out I was right, it was pretty easy. So what if it took 15 years of turning the idea round in my head to actually do anything about it? smile

New version

TL;DR:

Try these two settings in your config.ini to compare power to peak scaling:


[hijack]
voladjmed=0x2000,3000,0x1000,30,80
voladjhigh=0x2000,3000,0x8000,60,160


med is peak scaling, high is power scaling.

Details:

In this version the "headroom" parameter is overloaded - if it's less than or equal to 1 (0x1000) then the scaling is based on peak sample, as in the olden days.

If you set it greater than 1 (say 0x4000) then scaling based on RMS of sample size is used (as a full buffer of samples of that size give the same energy the actual buffer) and the headroom parameter is used as a multiplier to convert from the RMS value to the peak value.

Why even do this multiplier thing? The main reason is that I still want to avoid clipping, and if we just used the raw RMS value then the algorithm would always be in clipping avoidance mode. It also means that the silence values are a bit more comparable, and the venerable fixed point routines don't lose most of their resolution.

If you want to tweak the parameters, I suggest that you might try headroom between 0x3000 and 0x5000, and leave the silence parameters around 30,60. If you increase headroom higher than that, it's probably sensible to increase the silence values. A good rule of thumb would be to multiply them by headroom/0x4000. (My example above has headroom=0x8000, and the silence values both multiplied by two.)

I have tested this a little bit on the command line, and hardly at all on the player. But feel free to download and have a go.

Richard.

Top
#366784 - 24/05/2016 11:50 Re: Normalization, EASY (long) [Re: Nils]
mlord
carpal tunnel

Registered: 29/08/2000
Posts: 13564
Loc: Canada
Hi Richard!

No problem for you if I incorporate the patch into a new Hijack?

And do you/Tony have opinions as to what the default settings should be for the various values, differences from the current defaults?

Thanks!

Top
#366788 - 24/05/2016 15:26 Re: Normalization, EASY (long) [Re: mlord]
tfabris
carpal tunnel

Registered: 20/12/1999
Posts: 30696
Loc: Seattle, WA
I'd need to experiment with the new version before forming an opinion about the settings. It might be quite some time before I get to that, so don't wait on me. :-)
_________________________
Tony Fabris

Top
#366795 - 24/05/2016 23:17 Re: Normalization, EASY (long) [Re: mlord]
rjlov
member

Registered: 16/12/1999
Posts: 188
Loc: Melbourne, Australia
It would be great if you could add it to hijack, Mark.

However, there was a bug if you set headroom to 8 or above (0x8000) as in my example parameters! Should be fixed now. If headroom is unsigned in struct voladj_state then you have the good version.

My feeling is that 0x2000,3000,0x4000,30,80 will be a good replacement for the "high" setting. That may have too many sudden adjustments to avoid clipping. The low setting probably doesn't care too much if you use power or peak.

These are all just guesses, though, they could be wrong. I'm keen to do some more of my own testing too, but I'm not driving much lately.

Richard.

Top
#366814 - 27/05/2016 13:05 Hijack v520 is released [Re: rjlov]
mlord
carpal tunnel

Registered: 29/08/2000
Posts: 13564
Loc: Canada
Hijack v520 is now available.

The only changes are the new VolAdj code from this thread, plus the new (experimental) default settings for the VolAdj "High" setting.

Cheers

Top
Page 1 of 2 1 2 >