Is there a quick, not much processing time needed, way to make the same volume on a 16 signed int stream in real time? I've heard of replaygain, rms, and fft now, but I don't think I have the processing time able to devote to doing a perfect job of making multiple streams the same volume in decibels. Is there a quick way / algorithm I can look at the stream of 16 bit integers that will do a sufficient job? I don't think I have the processing time available to consider all the frequencies, how loud they are perceived, the energy, and averaging the DC component. Thanks, SA Dev
Is there a quick, not much processing time needed, way to make the same volume on a 16 signed int stream in real time?
Started by ●February 24, 2004
Reply by ●February 24, 20042004-02-24
SA Dev wrote:> Is there a quick, not much processing time needed, way to make the same > volume on a 16 signed int stream in real time? > > I've heard of replaygain, rms, and fft now, but I don't think I have the > processing time able to devote to doing a perfect job of making multiple > streams the same volume in decibels. Is there a quick way / algorithm I can > look at the stream of 16 bit integers that will do a sufficient job? I > don't think I have the processing time available to consider all the > frequencies, how loud they are perceived, the energy, and averaging the DC > component. > > Thanks, > > SA DevI don't know what you want. It's obvious that you can't control what you aren't able to consider. You need to decide how good "good enough" is. Jerry -- Engineering is the art of making what you want from things you can get. �����������������������������������������������������������������������
Reply by ●February 24, 20042004-02-24
Hi Jerry,> I don't know what you want. It's obvious that you can't control what you > aren't able to consider. You need to decide how good "good enough" is.I have a function that is getting 44.1khz samples (16bit) and I would like to make it output at a consistent volume between streams... It would be great to have the streams (different volumes) come out within a few decibels of each other... I realize that the volume may have to adjust since the stream is realtime and I don't know if any louder volumes are coming down the line, but that is ok. Thanks for the help, SA Dev
Reply by ●February 24, 20042004-02-24
SA Dev wrote:> Hi Jerry, > > >>I don't know what you want. It's obvious that you can't control what you >>aren't able to consider. You need to decide how good "good enough" is. > > > I have a function that is getting 44.1khz samples (16bit) and I would like > to make it output at a consistent volume between streams... It would be > great to have the streams (different volumes) come out within a few decibels > of each other... > > I realize that the volume may have to adjust since the stream is realtime > and I don't know if any louder volumes are coming down the line, but that is > ok. > > Thanks for the help, > > SA DevI still don't know what will make you happy and what will miss the mark; what you would like at best and what you would be willing to settle for. There are volume compressors used to maintain a constant output level regardless of how the program material changes. The "ride gain" on the signal, greatly diminishing the difference between crescendos and diminuendos. They are good for speech (most tape recorders suitable for meetings and dictation use them, but they make music sound rather insipid. The best of them are quite good; it may do your job. What hardware will you use to implement your device? How will the software be written? There may be commercial units you can buy. If you intend to look for those, look both for compressors and companders. Jerry -- Engineering is the art of making what you want from things you can get. �����������������������������������������������������������������������
Reply by ●February 24, 20042004-02-24
Jerry,> >>I don't know what you want. It's obvious that you can't control what you > >>aren't able to consider. You need to decide how good "good enough" is.I'm sorry I'm not giving enough info. I am working with software that emulates old arcade games, each arcade game may play its sound at a different volume. Most of the games use old antiquated sound chips, or even discrete components to generate the sound. What I would like to do is make all the games have the same volume. I have access to a function that gets each sample and can change it. Perfection would be a function that can alter the sample values in such a way that they register exactly the same decibel volume level on my sound level meter. Acceptible would be +-4 db I would think... Let me know if that helps or if you need more info, thanks for the help, SA Dev
Reply by ●February 24, 20042004-02-24
SA Dev wrote:> > I'm sorry I'm not giving enough info. I am working with software that > emulates old arcade games, each arcade game may play its sound at a > different volume. Most of the games use old antiquated sound chips, or even > discrete components to generate the sound. What I would like to do is make > all the games have the same volume. I have access to a function that gets > each sample and can change it.Must this be done in real time or is it possible to analyze the sound produced by each game as it is installed, for example? If the latter, you can do the root mean square calculation to determine an average level for each such game, save it somewhere, and apply a fixed gain (numerical multiplication factor) to each sample at play time that is a the ratio of the desired average level to the predetermined level of the game. To do this purely in real time will require "automatic level control" wherein you compute a real time approximation to the RMS value and adaptively adjust a gain accordingly which you apply to the samples as you play them. I haven't done that myself but I'm sure someone here can offer a snippet of C code that does the ALC sensing and gain application. Bob -- "Things should be described as simply as possible, but no simpler." A. Einstein
Reply by ●February 25, 20042004-02-25
Hi Bob,> Must this be done in real time or is it possible to analyze > the sound produced by each game as it is installed, for > example? If the latter, you can do the root mean square > calculation to determine an average level for each such > game, save it somewhere, and apply a fixed gain (numerical > multiplication factor) to each sample at play time that is a > the ratio of the desired average level to the predetermined > level of the game.Yes, someone elses approach was similar to this (they didn't use RMS, but rather just rather just peaks to determine if the volume was too loud). They started out at 10 times normal volume and reduced the volume if necessary to make it fit within the 16 bit integer. Then they stored the multiplication factor so the game would start out next at the already reduced factor. So, one time the game was run, sounds at first might be louder than they should be until the loudest sounds of the game were encountered, but then they would be leveled out. The problem is that their idea of looking at the peaks only resulted in wide variations between games. I think that is the part of their logic that is flawed. I agree with the store multiplication factor, but the technique for using the peaks to determine volume doesn't work well. That is what I'm trying to improve. Thanks! SA Dev
Reply by ●February 25, 20042004-02-25
"SA Dev" <nospam38925@forme.com> wrote in message news:403c9ab5@news.tulsaconnect.com...> Hi Bob, > > > Must this be done in real time or is it possible to analyze > > the sound produced by each game as it is installed, for > > example? If the latter, you can do the root mean square > > calculation to determine an average level for each such > > game, save it somewhere, and apply a fixed gain (numerical > > multiplication factor) to each sample at play time that is a > > the ratio of the desired average level to the predetermined > > level of the game. > > Yes, someone elses approach was similar to this (they didn't use RMS, but > rather just rather just peaks to determine if the volume was too loud). > They started out at 10 times normal volume and reduced the volume if > necessary to make it fit within the 16 bit integer. Then they stored the > multiplication factor so the game would start out next at the already > reduced factor. So, one time the game was run, sounds at first might be > louder than they should be until the loudest sounds of the game were > encountered, but then they would be leveled out. The problem is thattheir> idea of looking at the peaks only resulted in wide variations betweengames.> I think that is the part of their logic that is flawed. > > I agree with the store multiplication factor, but the technique for using > the peaks to determine volume doesn't work well. That is what I'm tryingto> improve."using the peaks doesn't work well" in what way? You might consider averaging (lowpass filtering) the peaks so the highest one or two don't drive the result - IF that's your concern. Fred
Reply by ●February 25, 20042004-02-25
Hi Fred,> "using the peaks doesn't work well" in what way?I've sent two files up to my FTP site at: http://home.earthlink.net/~alank2/newasteroid.wav and http://home.earthlink.net/~alank2/newpengo.wav The newasteroid.wav has much louder peaks, but is only 58db when I play it on my system. The newpengo.wav has lesser peaks, but is 75db when I play it on my system. I'm using a cheap SPL meter, radio shack digital set to MAX (report max), Fast, and Weighting "A". Thanks, SA Dev
Reply by ●February 25, 20042004-02-25
Fred Marshall wrote:> "SA Dev" <nospam38925@forme.com> wrote in message > news:403c9ab5@news.tulsaconnect.com... > >>Hi Bob, >> >> >>>Must this be done in real time or is it possible to analyze >>>the sound produced by each game as it is installed, for >>>example? If the latter, you can do the root mean square >>>calculation to determine an average level for each such >>>game, save it somewhere, and apply a fixed gain (numerical >>>multiplication factor) to each sample at play time that is a >>>the ratio of the desired average level to the predetermined >>>level of the game. >> >>Yes, someone elses approach was similar to this (they didn't use RMS, but >>rather just rather just peaks to determine if the volume was too loud). >>They started out at 10 times normal volume and reduced the volume if >>necessary to make it fit within the 16 bit integer. Then they stored the >>multiplication factor so the game would start out next at the already >>reduced factor. So, one time the game was run, sounds at first might be >>louder than they should be until the loudest sounds of the game were >>encountered, but then they would be leveled out. The problem is that > > their > >>idea of looking at the peaks only resulted in wide variations between > > games. > >>I think that is the part of their logic that is flawed. >> >>I agree with the store multiplication factor, but the technique for using >>the peaks to determine volume doesn't work well. That is what I'm trying > > to > >>improve. > > > "using the peaks doesn't work well" in what way? > > You might consider averaging (lowpass filtering) the peaks so the highest > one or two don't drive the result - IF that's your concern. > > FredWhatever the criterion, if there's a chance that the gain product might exceed the integer range, then you have to saturate rather than wrap around, and to do it right, you ought to low-pass filter to smooth the hard corners due to clipping. (But you'll get by if you don't.) Jerry -- Engineering is the art of making what you want from things you can get. �����������������������������������������������������������������������
