I've been reading some of the mp3 patents and it appears to me (as someone with no general legal experience, no deep knowledge of patents, or great understanding of the inner workings of mp3) that some of them could be worked around easily if you cared more about avoiding patents than you did about making full use of the specification. And since many of the patents are expiring already a workable patent-free subset may already, or soon, be possible even before the very final patent expires around 2017.

This seems to be a patent on the concept of switching between different joint stereo modes based on the audio content. So a simple workaround would be to only produce mono files. No stereo means no joint stereo, means no switching between joint stereo modes, means absolutely no possible infringement of this particular patent (and if your intended input or output format was mono in the first place, absolutely no loss in quality compared with patented methods). If similar could be done for each of the remaining 12 (according to the link above) patents then you could include such an encoder in F/free software, and distribute mp3s created with such an encoder in games or in streaming radio without paying any fees and have them decoded by any standard-compliant decoder.

Note that I think for the example above, you could easily have stereo files without infringing the patent as long as you only had one stereo mode per file but I went with the mono example because it makes the non-infringement clearer. Maybe you could be very sneaky and still switch modes as long as you did it in a very slightly different manner from that described in the patent and get some further improvment in quality as a result. For all I know, maybe lame already does this differently/better than the patent. But that's just icing on the cake. Having *anything* that produces compatible mp3 files, even at a cost of reduced quality or flexibility would be a start and be useful to *someone* since mp3 is generally used today for compatability reasons rather than because of its technical qualities.

I'd like to know if there has been any concerted effort by people who actually understand this stuff (on both the legal and technical side) to create a functioning mp3 encoder and/or decoder that works around all known patents. Is it possible? At what cost in functionality, quality, bitrate etc. If not, which particular patent(s) are the blockers which you can't possibly work around and without which you cannot have a compatible, non-ear-killing mp3 and when does the last of them expire?

(There's also the interesting sub-issue, which seems to apply to most modern lossy codecs, which is if your encoder is doing something incredibly clever (and/or patented) to decide when to switch between different encoding modes, but your decoder is dumb as a rock and simply does what the encoded file tells it to, does the patent for the encoder process have any impact on the decoder?)

I'm guessing the messed up nature of patents means no-one with an actual business to protect is going to want to risk this when there are feasible alternatives (e.g. pay the fees or use vorbis) but it seems like it might be an interesting intellectual excercise anyway and some free audio tools (e.g. Audacity) might include such a thing if the general consensus was that it was possible (just as some people would avoid Vorbis because "you can never be sure" about patents, but it hasn't stopped most reasonable people).

I found several other lists of patents, including the ones you didn't list, put them in a table, and read through the claims of all of them. I'm not sure all of the expiration dates are correct, this is tricky to determine.

Based on what I know of the MP3 standard, writing a patent free encoder should be possible the 24th of September 2013, but not before that. I am not so sure about a decoder, as many patents describe systems consisting both of encoders and decoders. How can decoders guarantee the encoder didn't use a certain technique? Additionally, there is one patent that I believe the encoder can avoid, but a standards compliant decoder wouldn't.

Someone who's even more familiar with the MP3 spec can probably confirm/deny/correct some of these.

Avoiding 5559834 by commenting out the butterfly code is not just "odd" or "strange". The aliasing is really, really bad.

I'm trying to get a handle on some objective measure of "really, really bad". I assume those are at the same bitrate. How much would you have to increase the bitrate on the hacked version for it to match (visually and/or audibly) the patented version? Is it even possible? How does that bitrate increase generalize to other types of audio such as speech or popular music?

I'm trying to get a handle on some objective measure of "really, really bad". I assume those are at the same bitrate. How much would you have to increase the bitrate on the hacked version for it to match (visually and/or audibly) the patented version? Is it even possible? How does that bitrate increase generalize to other types of audio such as speech or popular music?

Both examples above were compressed to 128 kbps. Increasing this to 320 did not create any visual or audibly difference.

The reason that the butterfly process can not be left out from the encoding is that the reverse butterfly process is performed in the decoding. I made a test where I removed the butterfly on encooding+decoding and ended up with a near-perfect result. No visually or audibly difference on the swept sine.

I think the reason for adding the butterfly process in the first place, is to handle the situations where one band is included but the next band is left out due to the perceptual filtering. I have not been able to create a synthetic signal where this is visible/audible though, expect at 32 kpbs where I did get some fuzziness on the graphics.