Skip to main content

Notice

Please note that most of the software linked on this forum is likely to be safe to use. If you are unsure, feel free to ask in the relevant topics, or send a private message to an administrator or moderator. To help curb the problems of false positives, or in the event that you do find actual malware, you can contribute through the article linked here.
Topic: Patent expiry dates and software for AMR, AMR-WB, and AMR-WB+ (Read 10003 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Patent expiry dates and software for AMR, AMR-WB, and AMR-WB+

Recently I've become interested in the AMR codecs, but it seems there isn't much software around to encode with.

At the same time, I was wondering about patents, and when they might expire. Given they're about ten years "younger" than MP3, I guess approximately ten years from now we'll see the first patents expire.

I'm kinda interested in the AMR codecs by 3GPP, because they see a lot of use in mobile communication. From what I've seen here, AMR-WB and Opus are quite comparable, and it's very much down to the sample which one wins out. It's not like one is better universally than the other, at comparable bitrates, etc.

For AMR and AMR-WB there seems to be VisualOn and OpenCore libraries available, but AMR-WB+ seems kinda barren, the list on Wikipedia doesn't mention any library or software for AMR-WB+ coding, so I don't know.

I remember there were lists where various patents along with their expiry dates were listed for MP3 and I think AAC, although I can't find them just now, they were on some Wikia page or something. I wonder if such things exist for AMR, and if it is as complicated, too. I know that the various AMRs are covered by various patents from Nokia and NTT, and some other companies. There's a patent pool of course, etc. Also, there seems to be little information about what and how many patents are covering the AMR codecs. I can only guess that it's as chaotic and complicated as it was with MP3 with U-Boat patents and all that.

The ITU adopted AMR-WB as G.722.2, so that one sees the most use, I'd guess but the 3GPP codecs seem kinda interesting in general. I can imagine the companies behind AMR-WB and AMR-WB+ are kinda "protective" of their i.p., Wikipedia explains the licensing weirdness a bit. I'd imagine there's OSS code available similar to how LAME totally isn't MP3 - technicalities aside.

This is the first place where I'm asking for a list of patents covering AMR, AMR-WB, and AMR-WB+, as well as for libraries and software, preferably for Linux. At the same time, I wonder if someone in here did anything beyond using those codecs. I.e. developing encoders, decoders, working on libraries, etc. I might've seen one or two ABX result diagrams, where Opus was compared to AMR-WB, I wonder what software was used there, etc.

For Linux I found this: http://www.penguin.cz/~utx/amr
It's also the only thing I can find quickly in my repos, etc.

Re: Patent expiry dates and software for AMR, AMR-WB, and AMR-WB+

Reply #1
OK, I've found this: http://www.voiceage.com/Patent-Portfolio.html
I can't be sure if that's like an exhaustive list, and how reliable the expiration dates are. Also, are those world wide expiration dates?

Then, there's this: https://hydrogenaud.io/index.php/topic,95034.0.html
However, I can't find the source code anywhere, I'm guessing I'm looking in the wrong places, but there's no link given in that post.

I can only find this: https://portal.3gpp.org/#55936-specifications
and when searching there for "AMR-WB+" it turns up four results, which seems to be all source code. Is that what is referred to in the post above?

Could someone help out?

 

Re: Patent expiry dates and software for AMR, AMR-WB, and AMR-WB+

Reply #2
Submarine patents were pretty much ended by 2000 due to trade agreements and legislative reform, so that's one MP3 etc complication unlikely to arise here. AMR was released in 1999; patents will presumably be expiring by 2020. AMR-WB and -WB+ are 3-5 years newer. Obviously there could be complications with the patent situation, and given that VoiceAge claims there are 150 essential patents in its AMR* portfolio, it would take real legal work to try to dig up a full list.

update now that I see your new post: a claim of 2024 for WB+ sounds realistic. They say WB patents expire in 2019 except for two "families," but I'm skeptical about them claiming 2022 & 2024 expiry for those two, which have 2000 & 2001 filing dates. AMR-NB sounds like it should be safe by 2020, as I was saying before.

Most AMR vs Opus tests I'm aware of are six and a half years old (Nokia, Google, etc tests with 0.9.0). (There's another with 1.1, but it was performed by Fraunhoefer&c forcing Opus to hard-cbr trying to make it look bad next to EVS/xHE-AAC.) There have been tons of improvements to Opus since then, while AMR has been unchanged.

Even in those tests, it's only at the lowest bitrates that AMR can compete. Opus is vastly better than regular AMR by 12kbps and noticeably better than AMR-WB at 20kbps and up. AMR-WB+ performed better than Opus at various bitrates in one test, but the test revealed issues with Opus which were resolved before 1.0.

It'd be interesting to see updated tests. I'd hazard a guess that Opus 1.2 is probably better than AMR-WB from 12kbps up. Much less info out there about AMR-WB+; it might be roughly comparable to Opus up to about 32kbps. (Its max rate is 48kbps.)

A quick google search comes up with this packaging of 3GPP AMR-WB+ reference code.

Re: Patent expiry dates and software for AMR, AMR-WB, and AMR-WB+

Reply #3
OK, the scheme in which these documents are filed is a bit strange, and it seems there's lots of duplication going on.
All files have been updated or at least checked on March of 2017, so they're not that old, or at least not that much out of date.
The specification documents are in .DOC (Microsoft Office 2003) format, out of all things - I can't even...

  • 26.273 contains source code an MSVC project files, and a compiled library and an encoder and decoder executable. Each have the suffix "_fx", which would be consistent with it being the fixed-point variant. While the .DOC file has been last changes in March 2017, the source code hasn't been changed since 2005 or 2006 depending on file.

  • 26.274 contains test vectors, as well as compiled versions of the encoders, decoders and libraries as well as companion programs in several directories (I don't quite understand the logic behind that, except perhaps convenience?). Both "_fx" and the floating point variants are scattered in various places here. No source code, though. The samples are interesting, though. All files, including the test samples are from 2005, except for some compiled files, which are from 2006, only the documentation has been updated in March of 2017.

  • 26.290 only contains a .doc document *sigh*, which explains the signal processing part. Transfer functions ( H(z) = ... ), and mathematical models are explained here, as well as a couple block diagrams, bode diagrams, and things like file formats are explained here as well. Last changed in March 2017.

  • 26.304 is very much like 26.273, it contains sourcecode, MSVC project files, a bit of documentation and compiled versions of the DLL, and encoder and decoder .EXE files. These are the versions without the "_fx" suffix in the name, which is consistent with what is mentioned in the 3GPP portal page, describing this as the floating point variant of the codec. Most of this code is slightly older, from 2004, with the latest changes to some of the source code in 2006. The documentation has been touched in March 2017.

It's hard to say if and what was changed in the main .DOC files warranting an update. For all I know, it might've been no changes at all, etc.

In general, there doesn't seem to be much maintenance going on. I can only imagine, that the reason why the fixed point variant and the floating point variant are kept in individual repositories, is just so they can be filed individually. There's really no reason not having both variants in one repository and simply have compilation rules for each variant. At the same time, it's just a matter of a couple functions to which this difference is pertaining. So they could be kept next to each other without confusion, etc. Maybe making licensing easier was another reason.

The repository mentioned in jensend's post, is essentially the floating point variant, re-uploaded and modified for compilation with autotools. I'll take a look at it later, perhaps.

Porting code from MSVC to GCC I find atrociously annoying, especially if the IDE is >10 years old...

EDIT: I've exported all .DOC and .RTF documents into .PDF in case anyone is interested.