I say Good Morning because I am retired and all day is morning.
I have movies, docs, and tv programs which I put on hard drives and supply an android box for older people, manly my 90 year old aunt.
I have been converting all audio to mp3 because Audition can normalize to 100%.
But I realize aac and ac3 is much better. Mp3 gain with the aac gain plugin can normalize aac but it is in db. Can I convert db to %?
Or is there something better.
My wife says I am 80 years old but I only confess to 29 so I am willing tg learn, if that what it takes
Is there a conversion between db and %
+ Reply to Thread
Results 1 to 19 of 19
Last edited by usually_quiet; 30th Jan 2023 at 23:06. Reason: typoIgnore list: hello_hello, tried, TechLord, Snoopy329
Depends on whether the % scale matches the decibel logarithmic scale. Personally, I wouldn't bet my money on it.
It works for me all the time,doesn't cause any clips and stays in the range.I think,therefore i am a hamster.
In digital audio highest level is called 0dBFS
It is recommended to not go over -3dBFS so whenever you normalize you should go for -3dBFS (or more correctly -3.0103dBFS i.e. SQRT(0.5) i.e. 0.707106781186548 i.e. 70.7106781186548%) .
General formula for conversion dB to % is provided here https://en.wikipedia.org/wiki/Decibel
I will digest this over a glasses of my homemade delicious wine. I thank all you for answering. You have expanded my knowledge and the enjoyment of several old people. Thank you.
Also may wish to look into videomass. It has two kinds of normalization algorithms. I believe both require two passes so it makes it easy.
Also just for a simple normalization use dynaudnorm
Noise Reduction to remove hiss, hum and increase volume on terrible audio quality of speeches / talks — played around with many different methods.
In videomass (ffmpeg frontend GUI)
-c:a libopus -vbr off -b:a 32k -ar 48000 -af highpass=200,lowpass=3000,afftdn,aformat=channel_l ayouts=stereo,volume=12dB,dynaudnorm
also tried highpass=500 and lowpass=1000 and it's not bad but not great for super super noisy. But just hiss and old recordings and especially for batch processing this can't be beat.
This show dynaudnorm
Decibel chart so anything 50dB or below seems good for marking it as silence as 60dB is for normal conversation.
I'm really sorry to say this but at the moment I am totally confused.
Audacity only exports aac to ac3 which my android box does not recognize. It exports aac to m4a which my android box does not recognize.
It does recognize aac for aac gain. But I have no idea how many decibels to put in for 100%.
Can anyone help me? If you live close I will supply you with my DELICIOUS homemade wine for life. Otherwise I will toast you for life when I have a glass, which is often.
When you export aac to m4a it's still aac,just mux the m4a to your video and it will be aac.I think,therefore i am a hamster.
Are you referring to the volume specified in the ReplayGain tags?
As far as volume goes there isn't one specified directly. There's a track or album gain tag, and both are relative to the ReplayGain target volume of 89dB, which is fixed in stone. You can adjust to a different volume, but the tags are always relative to 89dB.
89dB isn't a volume in normal human-speak though, it's a sound pressure level based on a SMPTE standard for movie theatres. ReplayGain's target volume of 89dB translates to a volume of -18dB on an output meter where 0dB is maximum.
The "track gain" or "album gain" tags simply say something like -3.7dB, which would mean the volume of the audio is 3.7dB louder than the target volume, and a player should reduce the volume by 3.7dB. It relies on the player actually supporting the tags though.
The only other ReplayGain info is the peak volume, which is relative to 0dB. So a peak of -2dB means the absolute loudest part of the audio is 2dB below maximum, but it has nothing to do with how loud the audio will sound. Normalising to 100% in Audacity only means the over-all volume is adjusted so the loudest part is at maximum (0dB on an output meter). Normalising to 89dB (-18dB) in MP3Gain (as opposed to peak normalising, which it can do) means the volume should always sound the same regardless of the peak level.
Edit: Thinking about it, the ReplayGain track and album gains are specified in dB, but the peak volume is specified as a percentage, where 1.0 = 100% and 0.8764 = 87.64% etc. I'd forgotten about that as even MP3Gain translates it to dB. So the tag itself might show a peak volume of 0.702890, which MP3Gain would display as a "Max Noclip Gain" of 3dB, whereas for foobar2000 in the screenshot below, the same peak volume would be shown as -3.06dB (slightly less rounding).
It's a fairly old version now, but try the version of foobar2000 below. It'll convert just about any audio format to any format, and you can scan the files for volume using ReplayGain and adjust the volume using that information while you convert. It's also set-up to display the volume in human-speak instead of using the ReplayGain "89dB" way of describing it. For MP3 and AAC it can adjust the volume losslessly as MP3Gain does, but it'll also do it while the audio's inside another container (such as MP4 or MKV) without having to extract it first. I should upload a newer version at some stage, but this one works and it'll get you started.
The screenshots in the link above don't show the contents of the volume tab, but when you load a bunch of files into a playlist, it displays the ReplayGain track gain info something like this (I've probably fiddled with it a bit since I uploaded that version). LUFS means "loudness units to full scale", which is another story, but LUFS and dB are interchangeable. I've added another column here to show the volume in the silly way ReplayGain defines it, so you can see how it compares to human-speak volume.
Edit: I've also added a second Peak column displaying the peak as a percentage, as it's stored in the ReplayGain tag.
[Attachment 69228 - Click to enlarge]
For TV programs, which are often more dynamic than the average pop-song, ReplayGain's target volume is a bit too loud. It'll likely result in peaks being clipped or above maximum. The official target volume for that sort of thing is -22dB/LUFS or -23dB/LUFS, depending where you live, but if you're converting the audio of TV shows they'd hopefully be at the correct volume to begin with... unless you downmix multichannel audio to stereo. There's presets for downmixing, but you'd need to downmix while converting to a lossless format first, scan and save the ReplayGain volume, then adjust the volume while converting to another format. There's also presets for compressing with the dynamic audio normaliser which work quite well, but once again it'd become a two step process.
Last edited by hello_hello; 14th Feb 2023 at 16:56.Avisynth functions - Audio Speed/Meter/Wave - CropPreview - CropResize - FixBlend.zip - Image/FrostyBorders - AnyResizer/CropResize MeGUI - Position.zip - Resize8 Mod
All this is always relative - in proper way normalization is performed to fully utilize dynamics of the system - mostly bit depth of Analog to Digital Converter - this is important for quantization noise - if 0dBFS is reference then every -6dB efficiently reduce system dynamics by 1 bit - so everything shall be normalized between -3dB and -6dB to avoid unnecessary loss of signal quality... -3dB is sufficient level to prevent signal clipping. Arbitrary levels such a as "89dB" are simply wrong - they should be applied not in digital domain but in analog domain (after Digital to Analog Conversion).
True, although I assume a 1 bit reduction in dynamics would be for lossless 16 bit audio or for lossy audio that's decoded as 16 bit, rather than higher bitdepths. Unfortunately support for something like ReplayGain tags in playback devices is far from the norm anyway, so the only alternative is to adjust the actual volume of the audio files themselves.
Plus, as a fixed volume is becoming common place these days (even streaming sites such as YouTube and Spotify are using one, although I think they both use -16dB) there's no longer an incentive to overly compress the audio to make it sound louder. In fact with a fixed volume, overly compressed audio won't sound as good.
Out of curiously I checked the audio in my library (all normalised to fairly close to -18dB) and there's 3307 tracks with peaks of -6dB or greater. In the interest of full disclosure, a dozen or so of those have peaks a tad over 0dB, but as long as it's only by a small amount I don't fuss over that too much. That leaves 2417 tracks with peaks lower than -6dB. Out of those, 2347 of them have peaks of -10dB or greater, and 74 have peaks below -10dB, with -12.12dB being the lowest.
In the end though, a small precision loss is a worth-while trade off for being able to put all 5800 tracks (approximately) on my MP3 player (should they fit) and listen to the the lot in any order without ever having to adjust the volume. At least it is for me.
Last edited by hello_hello; 14th Feb 2023 at 15:52.Avisynth functions - Audio Speed/Meter/Wave - CropPreview - CropResize - FixBlend.zip - Image/FrostyBorders - AnyResizer/CropResize MeGUI - Position.zip - Resize8 Mod
Issue with mp3 and similar codecs is clipping as they behave similarly to analog filter bank - this can be easily detected when spectrogram is generated - above max signal frequency easily some signals up to sample rate/2 can be visible - presence of such signals is clear manifestation of clipping and distortions.
I have impression that most of mp3 files (really like70..90%) is clipped, at some point this is not only visible in spectrogram (with commonly harmonics floor around -60..-80dBFS) but also audible... Clear manifestation of high crest factors and normalization to levels above -3dBFS...
16 bit is still most popular especially in mobile devices where power budget leading to simplification... with proper noise shaping even 10..12 bit can be OK but proper noise shaping can be also costly in terms of processing power... so usually developers using flat TPDF dither with no noise shaping so in overall every bit counts.
If I can, I tend to encode MP3/AAC audio with peaks close to 0dB and then adjust the volume of the MP3/AAC audio losslessly to -18dB afterwards, so at least the maximum dynamic range is being encoded. Whether that makes much difference I don't know, but it does effect the audio bitrate. It tends to be a bit higher than if the volume was adjusted down before it's encoded.
One of MP3's problems is the LAME command line encoder accepts float for the audio input, but converts that to integer for encoding, so even though the audio might enter unclipped, peaks above 0dB are clipped before it's encoded. The version of the LAME encoder that comes bundled with ffmpeg doesn't suffer from that issue, although from memory it doesn't cope with peaks more than a few dB above zero anyway. And of course even if the peaks aren't clipped during the encoding process, it could very well happen when the MP3 is decoded.
A huge percentage of CDs have tracks with sample peaks at 0dB, so when the waveform is reconstructed they often have peaks slightly above that, and most people probably convert CD tracks to MP3 under the assumption they can't have clipped peaks. I know I used to. And as lossy encoding tends to increase the peaks a little anyway, that only makes the problem worse.
Mind you I'm old enough to have spent many of my younger years listening to audio on cassette tape, so that gives me a fairly forgiving perspective when it comes to the problems of digital audio and/or lossy encoding.Avisynth functions - Audio Speed/Meter/Wave - CropPreview - CropResize - FixBlend.zip - Image/FrostyBorders - AnyResizer/CropResize MeGUI - Position.zip - Resize8 Mod
There is many different things mentioned by you.
First adjusting (in digital domain) digital level is always lossy as it require re-quantization and quantization is lossy part of digital signal processing.
Higher bitrate may be direct outcome of re-quantization distortions so despite higher bitrate there is no quality gain - counterproductive - similar to multiple time re-encoding with help of lossy encoders - this always leading to increased artifacts and generally to increased bitrate too.
Never analyzed LAME code so can't say if LAME use internally only integer or not to encode mp3, i would rather say that LAME should use internally floats as DCT natively is float type of function - there are special integer mp3 encoders targeting embedded devices (in past float was uncommon thing in embedded world).
But float itself is not magical answer for clipping and generally digital signal processing even if people believe that float is automatic way to avoid such problems...
CD is is something else - theoretically it is not lossy as final type of storage - under some assumptions creator of CD content may believe that 0 dBFS is safe and generally it should be safe if whole signal path is properly designed... But life may be not as simple. There is very old paper describing issue https://service-tcgroup.tcelectronic.com/media/Level_paper_AES109.pdf
Levels in digital world should be normalized against dBTP (decibel True Peak) but it is generally safe to assume that 0dBTP = -3.0103dBFS - so to simplify whenever dBFS is used it is safe to normalize level between -3.0103..-6.0206dBFS (this is loss between 0.5..1 bit from overall bithdepth and knowing that dither is used in all target type formats such as CD and that general rule is using TPDF dither and knowing that TPDF dither require at least 2 bits level then loosing 0.5..1 bit from overall signal resolution is not a problem especially that in most critical parts of spectrum using noiseshaping may deliver 20..23 bits perceived resolution it is even less problem).
I'm quite old too, probably older than you, being also electronics engineer i know how this works inside - magnetic tapes clipping is totally different than in digital world - magnetic tape has soft knee characteristic (magnetic saturation is not strict as in digital world) clipping is way less annoying and as noise is omnipresent in analog world then it will mask clipping (other distortions) significantly. Digital world is noise free (unless intentionally added to improve overall linearity) also clipping nature is very strict and easily perceived as frequently it is correlated with signal i.e. something that our ears/brain is very sensitive (first CD recording was faulty not because clipping but lack of noise/dither to act as linearizer for quantizers to decorelate quantization errors from signal) - we understand how noise/dither important is at the beginning of 90's. Thanks to this you can for example have on CD present signals with level like -140dB even if this way lower level than nominal -92dB (16 bit capability).
Btw I don't like idea of loudness level in signal normalization as loudness is subjective perception of the signal level - this is objective level multiplied by unique personal acoustical perception so even if we use something like Fletcher Manson curves, loudness means that we may perceive signal level differently. As such LUFS can be misleading at some point.
Last edited by pandy; 17th Feb 2023 at 13:04.