MP3 decoder

[ls02]

Does anyone know of any MP3 decoder either as source code or as
Android native library that can be used in android commercial
software?

[Olivier Guilyardi]

Hi,

liblame is LGPL. You may use it if you respect certain rules, such as offering
users a way to relink. It was a bit complicated, but I did this in my app for
some other LGPL libs, and it works fine. I can give more details if you like.

You might also want to look at FFMpeg. It's usually very optimized, and I'm
almost sure they have their own (LGPL) decoder.

libmad is nice too because fixed-point. However, this one's GPL, but a
commercial license can be acquired from Underbit.

You could also try and dig into Android source code, maybe there's a BSD decoder
in there?

Anyway, don't forget that mp3 is patented, and whatever lib you use, putting a
decoder into your app may cost you quite a lot of money :(

--
Olivier

[Onur Cinar]

Hi,

I'm not sure about the legal side, but I believe that it makes sense
to rely on the existing OpenCore libraries for MP3 decoding, since
they should already be tested and optimized for the platform.

The MP3 decoder library is provided in libpvmp3 library, and the files
are in /platform/external/opencore/codecs_v2/audio/mp3/dec . Although
it is not part of the public API, I believe that it won't change too
frequently.

Regards,

-onur

---
www.zdo.com

[ls02]

So can I take mp3 decoder sources from Android core, compile them into
my own native library with either no or minimum changes and use them
in my Android app?

[Onur Cinar]

Hi,

Yes those are the two options. Since the code is not too big, it could
be easier to compile it as a part of the library file, and this will
also make it more portable since you won't need to worry about any
private API changes.

The alternative would be, as you described, using the existing library
on the system to do the operations, but this can easily stop working
if the API gets changed by a system update. For example, on 2.2, It
looks like the library is now named as libomx_mp3dec_sharedlibrary.so.

I would move forward with the first option, since it is much cleaner.
Looks like the actual source code for the codec is covered by the
Apache License 2.0.

Regards,

-onur

---
www.zdo.com

[Onur Cinar]

Hi,

By the way, I forgot to mention the location of the files.

The GIT repository is:
git://android.git.kernel.org/platform/external/opencore.git

And the MP3 related files are under:
./codecs_v2/audio/mp3

Regards,

-onur

On Jun 15, 12:17 pm, Onur Cinar <onur.ci...@gmail.com> wrote:
> Hi,
>

> Yes those are the two options. Since the code is not too big, it could
> be easier to compile it as a part of the library file, and this will
> also make it more portable since you won't need to worry about any
> private API changes.
>
> The alternative would be, as you described, using the existing library
> on the system to do the operations, but this can easily stop working
> if the API gets changed by a system update.  For example, on 2.2, It
> looks like the library is now named as libomx_mp3dec_sharedlibrary.so.
>
> I would move forward with the first option, since it is much cleaner.
> Looks like the actual source code for the codec is covered by the
> Apache License 2.0.
>
> Regards,
>
> -onur
>
> On Jun 15, 11:06 am, ls02 <agal...@audible.com> wrote:
>
>
>
> > So can I take mp3 decoder sources from Android core, compile them into
> > my own native library with either no or minimum changes and use them
> > in my Android app?
>

---
www.zdo.com

[Doug Schaefer]

The only problem I can think of by doing that, and anything with mp3 I
guess, is the patent issue. I assume the handset vendors have covered
the royalties, but not being a lawyer, I'm not sure how that works.

Frankly, I'd just pass the mp3 up to the Java layer and play it from
there, at least until some official audio APIs arrive for the NDK, if
they do at all...

> --
> You received this message because you are subscribed to the Google Groups "android-ndk" group.
> To post to this group, send email to andro...@googlegroups.com.
> To unsubscribe from this group, send email to android-ndk...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/android-ndk?hl=en.
>
>

[Olivier Guilyardi]

I'm not a lawyer as well, but I agree with the Doug, it's better to use the SDK
Java API for playing mp3. Embedding your own encoder or decoder into your app
requires patent licensing from what I understand. When you use the SDK, you do
not ship any decoder, you just happen to use the one which is already installed
on the phone.

Olivier

[ls02]

I cannot use Java APIs since Android does not provide option to decode
raw bitstream. I also think that patent for MP3 decoder is free, it is
MP3 encoder that requires royalties. However, MP3 decoder
implementation may not be free, that's why I ask about the decoder
license.

On Jun 15, 3:48 pm, Olivier Guilyardi <l...@samalyse.com> wrote:
> I'm not a lawyer as well, but I agree with the Doug, it's better to use the SDK
> Java API for playing mp3. Embedding your own encoder or decoder into your app
> requires patent licensing from what I understand. When you use the SDK, you do
> not ship any decoder, you just happen to use the one which is already installed
> on the phone.
>
> Olivier
>
> On 06/15/2010 09:29 PM, Doug Schaefer wrote:
>
>
>
> > The only problem I can think of by doing that, and anything with mp3 I
> > guess, is the patent issue. I assume the handset vendors have covered
> > the royalties, but not being a lawyer, I'm not sure how that works.
>
> > Frankly, I'd just pass the mp3 up to the Java layer and play it from
> > there, at least until some official audio APIs arrive for the NDK, if
> > they do at all...
>

> >> For more options, visit this group athttp://groups.google.com/group/android-ndk?hl=en.- Hide quoted text -
>
> - Show quoted text -

[Doug Schaefer]

You might want to check out
http://mp3licensing.com/royalty/software.html. There is a listing for
decoder license fees.

[Olivier Guilyardi]

And don't miss the "Minimum Royalties" section on this page...

[mic _]

Why not add whatever additional data MediaPlayer needs to the raw bitstream on-the-fly and send the result to a ServerSocket on some free port, and tell your MediaPlayer instance to grab the data from the socket you created (localhost:somePort) ?

/Michael

[ls02]

I am not sure I understand what what you are proposing. MediaPlayer
can play as data source either MP3 file identified by full path or
file descriptor or an MP3 file URL. I need to decode MP3 bitstream
frame by frame.

> > android-ndk...@googlegroups.com<android-ndk%2Bunsubscribe@googlegr­oups.com>
> > .

> > > >> For more options, visit this group athttp://
> > groups.google.com/group/android-ndk?hl=en.- Hide quoted text -
>
> > > - Show quoted text -
>
> > --
> > You received this message because you are subscribed to the Google Groups
> > "android-ndk" group.
> > To post to this group, send email to andro...@googlegroups.com.
> > To unsubscribe from this group, send email to

> > android-ndk...@googlegroups.com<android-ndk%2Bunsubscribe@googlegr­oups.com>
> > .

> > For more options, visit this group at

[Doug Schaefer]

I thought there was an issue with how MediaPlayer handled streams,
i.e. it downloaded the whole thing before starting to play it. I was
looking at implementing an Internet radio when Android first came out
and ran into that. There were a few hacks people tried to work around
it, but it scared me off. Has this been resolved since Android 1.5? Or
am I just mistaken?