genie40204 wrote: JCJR wrote:
Just sayin, if an encoder has trouble with noisy high freqs (such as drums, cymbals, hand perc), or with transients in general, then one might suppose that we could make it easiest on the encoder to pre-filter out noisy high freqs and to minimize the transients? Of course such pre-processing would make many kinds of music sound worse before we even feed it to the codec, but it might help prevent the codec encoding chirpies, transient distortions, and other ear-annoying artifacts? On the theory that clean lowfi might be a more pleasant listen than nasty lowfi!
This sounds exactly like what I'd been thinking. I was unable to describe it as you did, but that is what I'm after.
Is this something that can be done? Or is this equally as difficult due to the aforementioned hurdles in this thread?
Is what JCJR suggesting doable?
Just wild guesses. I found one old source file. My current PC's don't have the old dev IDE installed so hunting thru lots of files isn't much fun. Here is one version of the old WMA writing--
The '//' comments were not necessarily my opinion at the time, more likely copying Microsoft documentation propaganda. IMO tis seriously doubtful for instance that "FM Radio Quality" is really FM Radio quality unless reception conditions are not optimal. Maybe the FM Radio Quality of a 10 dollar pocket radio 50 miles away from a 1000 watt college station.
Samplerates are not as bad as I recall if you don't need to go below 32 kbps. There were several ways to set up encode formats but the method below associated opaque data blocks made with some old funky windows tool to store GUID specifications which the codec would use. I'm reasonably sure these WMA 9 specs and code still work on Win 10 but Win10 may have better ways to do it. Someone could study current MS docs or do some code-testing to verify input samplerates for latest WMA capabilities.
So anyway it is silly word salad of little interest except denotes some possible bitrates and the associated necessary input samplerates in order for the codec to succeed.
- Code: Select all
(StereoOrMono, kbps, data size compression ratio, kilobytes per minute data size, IOW 5 minutes at 46 KB/Min might turn out about 230 KB file size, input samplerate)
//Low Bit Rate Voice (Mono, 6.5 Kbps, 192:1, 46 KB/min, 8000)
//FM Radio 28.8 K Modem (Mono, 28.8 Kbps, 68:1, 151 KB/min, 32000)
//FM Radio 28.8 K Modem (Stereo, 28.8 Kbps, 68:1, 152 KB/min, 22050)
//Higher Quality 56 K Modem (Stereo, 32 Kbps, 42:1, 242 KB/min, 32000)
//Near CD quality (Stereo, 48 Kbps, 28:1, 360 KB/min, 44100)
//CD Quality (Stereo, 64 Kbps, 22:1, 477 KB/min, 44100)
//Better than CD quality (Stereo, 96 Kbps, 14:1, 712 KB/min, 44100)
//Better than CD quality (Stereo, 128 Kbps, 11:1, 946 KB/min, 44100)
In other words, though WMA 10 might have different ways of working, if you want stereo 32 kbps then the WMA 9 codec probably expects an input file at 32 k samplerate. Or for stereo 28.8 kbps, the codec wants a 22.05 k samplerate input file. A tool capable of accepting a 44.1 k, 48 k, or 192 k file and spitting out a 28.8 kbps WMA, on WMA 9, PROBABLY has to temporarily samplerate convert to 22.05 k samplerate before feeding the codec, but it is a wild guess based on old information.
The nyquist, the highest allowable frequency in an audio file, is half of the samplerate. When samplerate converting down, frequencies higher than the new samplerate must be strongly filtered out or you get aliasing. Aliasing is ugly even if you don't subsequently feed the audio into a codec.
Possibly a very high quality samplerate conversion would do a better job than whatever process is wrapped up inside whatever encode tool you use. On the other hand, possibly the samplerate conversion inside the encode tool is excellent already and it would be wasted effort to try to do it better.
Lowpass filters can't be infinitely steep so usually there is a filter guard band. For instance the nyquist for 44.1 k samplerate is 22.05 kHz, but usually the lowpass filtering begins at 18 or 20 kHz or lower, so that the attenuation has become rather steep when we reach the 22.05 kHz nyquist.
The same-sized guard band for a 22.05 k samplerate would begin filtering around 9 or 10 kHz and be a very deep cut by the time it reaches 11.025 kHz.
An experiment you could make with a good stereo editor program, just to see if it makes any improvement-- Try to find a good quality steep lowpass filter plugin. A good "brickwall" filter. I am not familiar with current plugins and can't recommend one to try.
Rather than samplerate converting your source files, stay at 44.1 k or 48 k or whatever you usually use. Try brickwall filtering the file before low bitrate encode to see if it helps. You could try 10 kHz and then 5 kHz or lower. Regardless the quality of your encode tool samplerate conversion, if you wipe out high frequencies before sending to the encode tool then maybe it will help and maybe not. Needs experiment to determine.
At the very least, frequencies above nyquist need wiping out, but maybe a little lower than nyquist could help.
I mentioned "noisy high frequencies" such as cymbal, afuche, tamborine or whatever. POSSIBLY a codec could do better with (below nyquist) "pitched high frequencies". Or possibly the codec would mess up just as bad on pitched high freqs. That would be an interesting experiment.
If codecs at low bitrate really can do better with pitched high freqs, then it might be possible to locate or write a plugin somehow able to discern between noisy highs vs pitched highs, attenuating one and not the other. Merely a possibility, perhaps not a likely possibility.
Last edited by JCJR on Sun Nov 19, 2017 9:57 pm, edited 1 time in total.