Tag Archives: mp3

Aside

In a post in May, I wrote: “The patents which gave [Fraunhofer] revenue have barely expired on the format, and they’ve suddenly decided that MP3 is dead.” It appears that I fell for fake news, and I apologize. On rechecking, … Continue reading

MP3 is dead. Long live … what?

Update: My statement that Fraunhofer declared MP3 dead was completely wrong. Please read this retraction.

Girl Genius: The old Storm King is killed, and a new one promptly crowns himselfThere’s the blatantly obvious. Then there’s the blatantly cynical, who-cares-if-you-see-right-through me obvious. I’m not talking about Donald Trump but Fraunhofer. The patents which gave them revenue have barely expired on the format, and they’ve suddenly decided that MP3 is dead. They’ve even crowned its successor: not any open format, of course, but AAC, which can provide patent revenues for years.
Continue reading

The curtain falls on MP3 licensing

The site mp3licensing.com now redirects to the Fraunhofer website. MP3 licensing is a thing of the past.

MP3 licensing officially ends April 23

As I mentioned in my previous post, I wrote to the contact address on mp3licensing.com about why the site still said licensing was required. Today I got this response:
Continue reading

MP3 patent holders haven’t conceded

Update: Technicolor is conceding as of April 23.

Although it appears that all patents on the MP3 encoding have expired, the people collecting the licensing fees haven’t conceded. The FAQ on MP3Licensing.com still says:

Do I need a license to stream mp3 encoded content over the Internet? Yes.
Do I need a license to distribute mp3 encoded content? Yes.

For developers and manufacturers:

I want to support mp3 in my products. Do I need a license? Yes.
I have my own/third party mp3 software. Do I need a license? Yes.

Continue reading

Why MP3 freedom matters

Yesterday I mentioned MP3 Freedom Day to a friend, and he asked why it mattered. That’s something I should have explained. The MP3 patent holders, principally Fraunhofer and Technicolor, demand payment for any use of MP3 technology.

They even go after distributors of open source code. The Register reports:
Continue reading

MP3 Freedom Day, April 16, 2017

Get ready to celebrate! The last MP3 patent is about to expire! I think.

The Wikipedia article on MP3, as I’m writing this, claims that “MP3 technology will be patent-free in the United States on 16 April 2017 when U.S. Patent 6,009,399, held by the Technicolor[73] and administered by Technicolor, expires.” OSNews doesn’t list any patents beyond April 16. If they’re correct, then Easter will be MP3 Freedom Day!

Or maybe not. The “Big List of MP3 Patents (and Supposed Expiration Dates)” lists a patent which won’t expire until August 29. The Library of Congress cites this list in its discussion of the MP3 encoding format, though it doesn’t have any special authority. That patent looks dubious.
Continue reading

When do the MP3 patents expire?

MP3 logoWhy exactly is MP3 still popular? It’s not as efficient as more recent compression methods, and it’s encumbered by patents. People keep using what’s familiar. In a few years, it may become patent-free.

A Tunequest piece from 2007 lists several expiration dates that are still in the future:
Continue reading

Honda MP3 player defect

Recently Eyal Mozes hired me to determine why the sound system in his new Honda Civic wouldn’t play some MP3 files. This was a chance to do some interesting investigative work, and I’ve found what I think is a previously unidentified product defect.

He sent me twenty MP3 files, ten of which would play on his system and ten of which wouldn’t. First I ran some preliminary tests, establishing that iTunes, QuickTime Player, Audacity, and even my older Honda stereo had no trouble with the files. Then I ran Exiftool on them and looked at the output to see what the difference was.

The first thing I looked for was variable bitrate encoding, which is the most common cause of failure to play MP3 files. None of them used a variable bitrate. Looking more closely, I saw that all the files had both ID3 V1 and V2 metadata. This is legitimate. In the files he’d indicated as non-playable, though, the length of the ID3 V2 segment was zero. This was true in all the non-playable files, while all the playable ones had ID3 V2 with some data fields. I verified with a hex dump that the start of the files was a ten-byte empty ID3 V2.3 segment.

I continued looking for any other systematic differences, but that was the only one I found. It’s highly likely that the MP3 software in Eyal’s car — and, therefore, in many Hondas and maybe even other makes — has a bug that makes a file fail to play if there’s a zero-length ID3 V2 segment. (Update: Just to be clear, this is a legitimate if unusual case, not a violation of the format.)

Eyal had gone to arbitration to get his vehicle returned under the warranty; Honda’s response was unimpressive. Initially, he told me, Honda claimed that the non-playing files were under DRM. This is nonsense; there’s no such thing as DRM on MP3 files. They withdrew this claim but then asserted that “compatibility issues” related to encoding were the problem, without giving any specifics. The ID3 header in an MP3 file is unrelated to the encoding of the file, and I didn’t see any systematic differences in encoding parameters between the playable and non-playable files. Honda claimed to be unable to tell how the files were encoded. They may not have been able to tell what software was used, but the only “how” that’s relevant is the encoding parameters.

This problem won’t make your brakes fail or your wheels fall off, but Honda should still treat it as a product defect, come up with a fix, and offer it to customers for free. If they can upgrade the firmware, that’s great; if not, they’ll have to issue replacement units. The bug sounds like one that’s easy to fix once the programmers are aware of it. The testing just wasn’t thorough enough to catch this case.

If anyone wants to hire me for more file format forensic work, let me know. This was fun to investigate.

Making sense of MPEG audio formats

Lately I’ve been trying to clarify in my mind exactly how certain common MPEG-related audio formats are defined. I think I’ve got this right, but if anyone can offer corrections, they’d be appreciated.

MP3

This is the common name for MPEG-1 and MPEG-2, Audio Layer 3, which defines an encoding method. The difference between the MPEG-1 and MPEG-2 variants is just in the sampling rates. It’s audio-only. An “MP3 file” is normally a raw MP3 stream without a container.

MP4

MP4 means MPEG-4 Part 14. This is a container format which can hold audio, video, or both. It doesn’t specify the encoding method. In principle you could have an MP3 stream in an MP4 file. The preferred extension for MP4 containers is .mp4, but many others are used to denote specific encodings within MP4 containers.

AAC

This is short for MPEG-2 Part 7, Advanced Audio Coding. MPEG-4, Part 7 defines some extensions of it. That’s the encoding; several different containers may be called “AAC files” if they hold an AAC stream. A raw AAC stream file is possible but not common. MP4 is the most common container, so “MP4 audio” and “AAC” are often treated as if they were synonyms. HE-AAC, also known as aacPlus, is an MPEG-4 audio profile. HE-AAC decoders can decode AAC, but not vice versa.