Pre-Conditiong for Low-Bitrate WMA 9 Codec

[BertKoor]

In my searches, I came across a plug-in called UNCHIRP, which, although seems to have the right idea, focuses on MP3 and HE-AAC, not WMA 9.

You mean this plugin: https://www.zynaptiq.com/unchirp/unchirp-overview/ ??

* It does no preprocessing at the sending side, it acts as a restauration aid at the receiving side.
* The system requirements are much higher than your target platform
* Where do you get it focuses on MP3 / AAC and not WMA? These all suffer from similar artefacts...

WMA 9 is required because of compatability w/Windows 95 and 98 which do not support WMP 11.

So you go dumpster-diving for retired PCs, and repurpose them to become low bitrate digital radio receivers? And that's worth your time & money? I truely think these machines can decode AAC streams as well.

[stratum]

If there is any commercial use case for the idea then there should be other options - for example you can tell your mixing - mastering engineer to produce content more compatible with low bitrate codecs. That means having less sharp transients and less treble high end, perhaps even a different composition where necessary. Where there is a serious need these options would be considered and the result would be better than trying to develop a new plugin that would attempt to solve the problem in a general way. As to what that serious business case might be, I can imagine someone trying to release a new computer game for an ancient version of a game console, but who knows, perhaps delivering content over the web globally has similar restrictions.

[PurpleSunray]

If there is any commercial use case for the idea then there should be other options - for example you can tell your mixing - mastering engineer to produce content more compatible with low bitrate codecs.

Best idea is to ask the mastering engineer to produce low-bitrate files in addition to the <mastered>.wav
It adds what is missing with PreCode / pre-processing approach: the feedback loop.
The mastering engineer will (hopefully) listen to what he produced and if it sounds crap, he can modify the stream or encoder settings so that it sounds better.
Manual multi-pass encoding

[genie40204]

Hmm, well I found this blurb as well - does it make you any less skeptical?

"Orban’s PreCode technology manipulates several aspects of the audio to minimize artifacts caused by low bitrate codecs, ensuring consistent loudness and texture from one source to the next. PreCode includes special audio band detection algorithms that are energy and spectrum aware. This can improve codec performance on some codecs by reducing audio processing induced codec artifacts, even with program material that has been preprocessed by other processing than Optimod."

[genie40204]

Double post, sorry.

[PurpleSunray]

Hmm, well I found this blurb as well - does it make you any less skeptical?

"Orban’s PreCode technology manipulates several aspects of the audio to minimize artifacts caused by low bitrate codecs, ensuring consistent loudness and texture from one source to the next. PreCode includes special audio band detection algorithms that are energy and spectrum aware. This can improve codec performance on some codecs by reducing audio processing induced codec artifacts, even with program material that has been preprocessed by other processing than Optimod."

This the marketing blabla I was talking about

PreCode includes special audio band detection algorithms that are energy and spectrum aware.

So what is this algorithm?

If it is a compressor (energy aware) and EQ (spectrum aware) where they throw a preset into, it is the kind of the rough guessing I was talking about.

If it is something advanced that knows about the psychoacoustics modells of the encoders and trys to counteract processing problems by pre-processing the stream, they obviosly invested a lot of effort on that and invented something nobody else has. So why is there no patent on this? Or at least some paper that describes what it is about? And why nobody else had same idea (mabye they had, but it's not possible technically?)? Why is there no "Export for LowBitrate" on ProTools or Ablton? Or at least some extraordinary expansive 3rd party plugin to do that? Why does Orban not offer their technology to Mirosoft? They could add it to next WMA encoder and get rid of artefarts, w/o even modfying the encoder, just add that pre-processing.
I just don't beleve that they are able to solve problems outside of the encoder, where MS, Apple, Faunhofer, Nero .. engineers failed to solve it inside the encoder. If they are able, they should file a patent at least to make sure MS cannot analyze PreCode and added same processing to next WMA version.

[PurpleSunray]

I

WMA 9 is required because of compatability w/Windows 95 and 98 which do not support WMP 11.

So you go dumpster-diving for retired PCs, and repurpose them to become low bitrate digital radio receivers? And that's worth your time & money? I truely think these machines can decode AAC streams as well.

Just to make this clear once again.. if you stream WMA10 LBR, into a win95 that can only decode WMA9 on old WMP, it will be able to play it. It will sound shit, like up to now, because the old player only decodes the "wma9 part". BUT.. anyone with a current WMP version, which can also decode the WMA10 LBR part, will have way better quality.

In detail (Microsoft -> ):
There are two WMA codec versions. Let's call it WMAv1 and WMAv2.
WMAv1 has been created by Windows Media Encoders 2 until 8.
Starting from Windows Media Encoder 9, they create WMAv2.
So what you know as WMA9, WMA9.1, .. WMA10 is all same bitstream.
A player does not even know if it is a 9.1 or 9.2 stream.
The WMA file itself carries a baseband audio stream. This is what every player must be able to decode at least. A WMA9 encoder creates this.
If you encode with WMA10 LBR, you create same baseband audio stream again (more or less), but in addition to that, the file now also has addtional WMA10 LBR data.
Old WMA9-only players don't understand that and ignore it.
New WMA10 player understand it, and imporive the baseband audio with this informaiton.

[BertKoor]

https://sourceforge.net/projects/fcchan ... m%20Codec/

AAC ACM Codec by fccHandler
Note: Currently this codec can only decode AAC, it cannot encode AAC!
Version 1.9 (July 21, 2012)
Based on the open source FAAD2 library by M. Bakker of Nero AG.


AAC ACM Codec

Change Log started February 2011
=================================

Version 1.9 (July 21, 2012)
By request the x86 version now works on Windows 95 OSR2 and Windows NT 4.

[PurpleSunray]

The problem with switching to AAC-only, is that you force your listeners to install an AAC decoder - what most users won't do just to listen to that online radio.
Window Media Player on win95 cannot play AAC.
Internet Explorer on win95 also cannot play AAC.
But both can play WMA.

It just does not make any sense to limit yourself to a specific WMA encoder version.
Use the latest and greatest version with low-bitrate optimization on the sender-side. Receivers can handle it, also old ones.

[JCJR]

I'm retired and couldn't sustain the effort to write code. Was a few years since working with WMA encoding and it sounds like PurpleSunray is more up to date on details. I agree with BertKoor that it is sad to use intentionally degraded audio but I suppose there must be cases where it may be sensible. I wouldn't willingly use audio quality worse than the equivalent of 320 kbps MP3 for my own purposes.

Forgive if I'm remembering wrong, but so far as I recall both the Windows variant of fraunhofer mp3 encoder and also WMA encoding, when performed low-level from within a program-- In other words not calling some shell program that takes an input file name, an output file name, and then does the entire conversion writing the output WMA to disk. Rather, invoking the mystic runes of DirectX to call forth and enthrall the Properties of the Codec God, then sacrifice to the Codec god many small un-compressed memory-based audio buffers, receiving in turn memory buffers of compressed audio-- (It is a joke and poetic license, not necessarily definitive symptom of dementia ) And finally save the compressed audio to disk file or whatever else you might care to do with it.

Anyway, so far as I recall, at that low level neither the MP3 nor WMA encoding would accept any and all uncompressed file formats for direct conversion. The higher bitrates expected at least 44.1 k samplerate source audio. There may even have been a couple of funky bitrates that only worked for 48 k samplerate audio input.

But lower bitrates would fail conversion (using low level methods) if you sent the codec 44.1 k audio. Some of the intermediate bitrates would only work if you sent the codec 22 k samplerate or whatever. So far as I recall there were some bitrates demanding 11 k or whatever. The lowest bitrates needed low samplerate audio-- IIRC as low as 8 k samplerate. If you requested a low bitrate that wants 8 k samplerate input audio, then it would fail if you try to offer the Codec God anything except what it demands.

Maybe it is different nowadays, dunno. Any tool that will take a 44.1 k samplerate input file and spit out a low bitrate WMA or MP3, I would wildly guess that such a tool performs transparent internal samplerate conversion to offer up to the Codec God that which it requires.

My code used lookup tables of the samplerates required for each bitrate and did on-the-fly samplerate conversion depending on the user-selected desired bitrate.

Just saying, some samplerate conversion is better than others. If a tool has to SRC a 44.1 k file down to 8 k before feeding the codec, then if the tool's SRC is not very good-- Then maybe you get "cheezy samplerate converter chirpies" added on-top of "low bitrate chirpies"?

Just saying, MAYBE pre-converting the samplerate of the source audio to that demanded by the codec, as high quality possible, could avoid any Cheezy Samplerate Converter problems in the encode tool? If the bitrate demands an 8k samplerate, and you deliver an 8 k samplerate source file to the encode tool, then presumably the tool would be smart enough to know that it doesn't have to samplerate convert the audio on the way to the codec?

Alternately, rather than samplerate convert, you could just apply a good quality steep antialias filter to the source audio, while leaving the samplerate unmodified. If the codec is gonna expect 8 k samplerate, then brickwall filter that 44.1 k file at a little lower than 4 kHz before sending it to the encode tool.

Just some dumb ideas.

[PurpleSunray]

I have no idea what tools he is using what it takes to satisfy the Codec God (there might be SRC involved), but:

If the bitrate demands an 8k samplerate

the bitrate will not demand this.
The bitrate demands to cut the whole spectrum into small little pieces and than reduced / remove everything where the encoder thinks: humans cannot heart that anyhow.
If Pavarotti and budgie sing at the same time, I keep both at 320kpb, have enought bits. At 128 I'm gonna remove the budgie, need to save bits. At 32kpbs I need to cut Pavarotti into small little pieces, cuz no more bits...

[JCJR]

I have no idea what tools he is using what it takes to satisfy the Codec God (there might be SRC involved), but:

If the bitrate demands an 8k samplerate

the bitrate will not demand this.
The bitrate demands to cut the whole spectrum into small little pieces and than reduced / remove everything where the encoder thinks: humans cannot heart that anyhow.
If Pavarotti and budgie sing at the same time, I keep both at 320kpb, have enought bits. At 128 I'm gonna remove the budgie, need to save bits. At 32kpbs I need to cut Pavarotti into small little pieces, cuz no more bits...

Thanks PurpleSunray

I get what you are saying and agree that one wouldn't expect high fidelity from low bitrate audio.

OTOH in the old days under good receiving conditions AM Radio did not hurt the ears. Frequency response was limited but one could easily distinguish Pavarotti vs budgie.

Just in my past experience dealing at "low level" with the windows MP3 and WMA codecs, if I requested a certain bitrate, the codec expected a certain input audio samplerate. If I did not give the codec the samplerate it expected, then the codec would return an error code and the codec would generate no output. If the codec might expect an 8 k samplerate input for a certain bitrate output, then if I wanted the encode to succeed I had to give it the 8 k samplerate input. Maybe it is different today.

I was interested in higher bitrates but years ago when writing the features had to test all the bitrates to make sure they would work. Maybe a "well done" low bitrate encode ought to sound as smooth as an old tube living room AM radio console receiving the big band or orchestra records under ideal conditions? Though I suppose there may be more kinds of low bitrate encode degradations in addition to simple high frequency rolloff?

[PurpleSunray]

Though I suppose there may be more kinds of low bitrate encode degradations in addition to simple high frequency rolloff?

Yes, there are many
High frequency rolloff does not necessarily contribute much to compression (if there is no high frequency, it contributes nothing).
When you do compression, it is all about making numbers smaller.
To store a small value, you need less bits than if you need to store a big value. It's really that simple
So how make numbers smaller?
Instead of having a L and R channel with big numbers, I could convert to M+S.
Mid will have big numbers, but side-channels can have small numbers (it's just the difference to Mid).
If there is little stereo image, or I need to save bits, I could even join L+R to mono.
Then simply recuding dynamics (compressing on musical meaning) also makes numbers smaller.
Or removing budgie - it will do nothing else than reducing the amplitude on the frequncy bands where budgie sings on. Making bigger numbers smaller on this bands.

There is no general low-bitrate problem.
There are codecs especially made for low bitrate.
u-Law, GSM, Speex, .. they all handle low bitrates quite well.

The problem genie40204 struggels with, is that he is using a codec on 32kbps, that was not designed for it.
WMA has added low-bitrate support with WMA10 LBR. Until then 64k was kind of the lower limit.

If you go below, you bascially overdrive the filters inside the encoder and we all know that overdriven filters can sound strange

[JCJR]

Thanks PurpleSunray

Haven't studied low bitrate compression. Maybe there are good ones. Dunno. There are various strategies, dunno details. I seem to recall long ago reading about one of them that would encode each frame as a rough approximation with something like a weiner filterbank, also storing a savagely bit-reduced short datablock of the difference between the filter output vs the original input signal. Presumably the decode would synthesize the rough filterbank waveform then add the sparse difference bits on-top to make reproduction somewhat more accurate.

Regardless of method, perhaps the goal is to reduce information, reduce signal entropy, in ways least-obnoxious to the human perceptual system?

Maybe I remember wrong but long ago it seemed that 128 kbps was often to my ear unkind to transients, especially drums, cymbals, hand percussion. I would occasionally notice such problems even at 160 or 192 kbps, so settled on 320 kbps and lossless FLAC as standard for personal use. Less labor-intensive to always use "overkill" rather than laboriously listen to encoded music to find out if a particular piece had managed to survive a lower bitrate encode.

But noticed some orchestral music could sound great encoded less than 128 kbps, at rates low enough to completely butcher a stupid rock'n'roll ditty. However the low rate would probably butcher classical piano or harpsichord or whatever with lots of transients. Just that many full orchestra pieces are fairly mellow and smooth and apparently some codecs can reproduce that fairly well at low bitrate, so far as the ear can perceive.

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!

[PurpleSunray]

I think this could be possible, but it would be a lot of effort.
The filtering / transient shaping inside the encoder follows a psychoacoustic modell.
That is a set of rules that describes how humans hear and from this, the encoder decides what will be removed.
If there is a loud frequency at 2.0khz and two not so loud at 1.9khz and 2.1khz, it is likely that the two not-so-loud are even further reduced in amplitude or removed completly. Because psychoacoustic modell says that human ear&brain will focus on the loud 2.0kHz anyhow and so much on much on 1.9khz + 2.1khz because they are on the same "critical band" (humans focus on one frequency within one critical band). There are lot more of such rules.

So to pre-filter, you need to solve three basic problems:

1) Understand how the encoder processes the signal. That's the psychoacoustic modell.
For mp3 or aac you can find it on internet, for WMA you can not.

2) Understand how the rate control works.
The amount of filtering done on 1) depends on the amount of bits that come out the end of the encoder.
Encoders implement a "rate control" algorithm that adjusts parameters on the processing pipeline, depending no how many bits the encoding produces.
This also often depends on the input settings to the encoder. Rate control might work completly differnt on 2-pass encoding mode, compared to if you do low-latency single-pass encoding.

3) Understand how processing is implemented technically.
The extremly bad quality in wma9 with very low bitrates comes the problem that the encoder was not designed for it. Filters needs to cut that hard, so you end up with phase and rippling and rinning and whatever problems all over the bands.
If you want to understand the problems that come from running filters near (or over) their limits, you first need to understand how the filter design looks like.

Now.. all this could be done on an encoder where you have the source code. It is just lots of works.
But for a closed-source encoder such a wma ... hm... I wish you good luck