Re: MP3 decoder packaged with XMMS
On 7/15/05, Michael K. Edwards <m.k.edwards@gmail.com> wrote:
> Can you point me to a brief but technical summary of some of the Ogg
> Vorbis codecs? I would be curious to compare them against the MP3
> techniques, about which I know at least a little bit.
I am _not_ trying to create trouble here; anything I can figure out in
a couple hours of Googling is probably already on your (and your
potential opponents') radar. If anything, this illustrates how
difficult it can be to sustain work in this space without documenting
the things you have done that you think are original in the form of
patent applications, so you have something to bring to the table when
it's time to negotiate an industry standard and form a patent pool.
So I started by reading the Vorbis I spec, and it looks to me (on a
very quick reading, IANAL, TINLA, little green men squeezed this
through a pinhole in my tinfoil hat) like your decoder at least is
clean WRT Fraunhofer -- at the risk of pushing the possibility of
patent infringement onto the data stream itself. It's a bit like
selling silicon which doesn't become patent-infringing until the
firmware is loaded -- which is a perfectly good business strategy,
followed by many silicon and board-level vendors in A/V space.
Specifically, putting the codebooks in the header is clever, and I'm
guessing that Floor 1 gets you out of the trouble that Floor 0 might
have had any patent that specifies the Bark scale explicitly. There
are always Lucent's patents to worry about (#5790759, #5285498,
EP1160770, ... -- I can't believe they let this kind of crap through
the system), and you might want to scan the rest of
http://gauss.ffii.org/Search/All/IPC/G10L19/02 (maybe even all of
bloody G10L19), but I'm probably teaching my grandmother to suck eggs.
(If I were designing the codebook format, I might go for stratified
trees with room for a heap index so that I could do stabbing queries
and bulk insertion efficiently -- but that's really for streaming
applications, and matters more when you have hardware on the back end
that can only handle a minimal interlock during partial codebook
updates. Agile codebook switching might also help compete with G.729E
and modern equivalents. Xiph.org is welcome to reduce that idea to
practice and patent it, doing whatever they like with the economic
rights, as long as I am properly credited as co-inventor. :-)
Note that K. Brandenburg, co-author of the 1992 paper you cite as the
source of the MDCT, is almost certainly the same Karlheinz Brandenburg
who filed #5040217 (assigned to AT&T Bell Labs, now presumably held by
Lucent as well). A forward citation search for that patent number
might be in order; you might particularly be interested in #6,704,705
(assigned to Nortel).
By the way, where did you get the numbers in floor1_inverse_dB_table?
If that's an important part of the psycho-acoustic magic, its
provenance needs documenting, or it could get ugly in a court of fact
when an "expert witness" lies with numbers. The general public can't
tell what the significance of the difference between two
exponential-ish curves may be, and you don't have the say-so of a
patent examiner (for what that's worth) that your methodology does or
doesn't differ in some way from the prior art as of date X.
That's about all I can glean from the Vorbis I spec without long,
tedious grinding through the patent databases, which I'm not qualified
to do anyway. Now, is there any documentation about how the encoder
works? How do you go about tracking whose chocolate gets into your
peanut butter as people refine the encoding techniques?
Cheers,
- Michael
(IANAL, TINLA, I know jack about patents except what I learned when
filing one -- totally unrelated to audio -- with the help of a patent
agent (now attorney) whom I respect a great deal.)
Reply to: