#4044 - 02/05/2000 01:04
Normalization, EASY
|
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]
|
carpal tunnel
Registered: 20/12/1999
Posts: 31594
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 FabrisEmpeg #144
|
Top
|
|
|
|
#4046 - 02/05/2000 17:34
Re: Normalization, EASY
[Re: tfabris]
|
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]
|
carpal tunnel
Registered: 20/12/1999
Posts: 31594
Loc: Seattle, WA
|
Now that is insanely amazing and cool. You have our full attention. Let us know how it goes. Tony FabrisEmpeg #144
|
Top
|
|
|
|
#4048 - 03/05/2000 00:51
Re: Normalization, EASY
[Re: Nils]
|
addict
Registered: 15/07/1999
Posts: 568
Loc: Meije, Netherlands
|
Nils, could you send me your e-mail address? Henno ( [email protected]) Henno # 00120
_________________________
Henno
mk2 [orange]6 [/orange]nr 6
|
Top
|
|
|
|
#4049 - 03/05/2000 10:34
Re: Normalization, EASY
[Re: Nils]
|
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]
|
carpal tunnel
Registered: 20/12/1999
Posts: 31594
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 FabrisEmpeg #144
|
Top
|
|
|
|
#4051 - 03/05/2000 16:00
Re: Normalization, EASY (long)
[Re: tfabris]
|
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]
|
carpal tunnel
Registered: 20/12/1999
Posts: 31594
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 FabrisEmpeg #144
|
Top
|
|
|
|
#4053 - 04/05/2000 00:12
Re: Normalization, EASY
[Re: tfabris]
|
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]
|
carpal tunnel
Registered: 20/12/1999
Posts: 31594
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 FabrisEmpeg #144
|
Top
|
|
|
|
#4055 - 04/05/2000 15:01
Re: Normalization, EASY (long)
[Re: rjlov]
|
carpal tunnel
Registered: 08/07/1999
Posts: 5546
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.]
|
carpal tunnel
Registered: 21/05/1999
Posts: 5335
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]
|
carpal tunnel
Registered: 20/12/1999
Posts: 31594
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 FabrisEmpeg #144
|
Top
|
|
|
|
#4058 - 04/05/2000 20:21
Re: Normalization, EASY (long)
[Re: tanstaafl.]
|
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]
|
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]
|
carpal tunnel
Registered: 20/12/1999
Posts: 31594
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 FabrisEmpeg #144
|
Top
|
|
|
|
#4061 - 05/05/2000 19:53
Re: Normalization, EASY (long)
[Re: rob]
|
carpal tunnel
Registered: 08/07/1999
Posts: 5546
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]
|
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.]
|
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]
|
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]
|
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]
|
carpal tunnel
Registered: 20/12/1999
Posts: 31594
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
|
Top
|
|
|
|
#4067 - 29/05/2000 01:51
Re: Normalization, EASY (update)
[Re: tfabris]
|
carpal tunnel
Registered: 10/06/1999
Posts: 5916
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]
|
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]
|
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]
|
carpal tunnel
Registered: 20/12/1999
Posts: 31594
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
|
Top
|
|
|
|
#4071 - 08/07/2000 10:31
Re: Normalization, EASY (update)
[Re: tfabris]
|
carpal tunnel
Registered: 20/12/1999
Posts: 31594
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
|
Top
|
|
|
|
#4072 - 09/07/2000 15:59
Re: Normalization, EASY (update)
[Re: tfabris]
|
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]
|
carpal tunnel
Registered: 20/12/1999
Posts: 31594
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
|
Top
|
|
|
|
|
|