Wiki > Main > EncoderDiscussionMP3 (compare)
Difference: EncoderDiscussionMP3 (r2 vs. r1)
(Please refrain from flames here. Add facts. I tried to clear up previous arguments to make this page less "personal" / DanielStenberg)
There aren't very many free/open real-time MP3 encoders around.
We could use the Shine encoder by Gabriel Bouvigne, but it is very basic and needs quite a lot of work to achieve good quality. Any takers?
I've downloaded the source code, modified it so it compiles on my machine, implemented some intial hacks to get the ball rolling, but no gaurantee on the outcome. The sound quality is not the greatest, will require a lot effort to get a good encoder. Maybe 192kbps files will sound good -- DerickHugunin
I've found a fixed-point and optimized version of the Shine MP3 encoder for ARM and StrongARM, which should be portable to Coldfire. On a closer look, there are some double's left (initialization routines etc). Description Source
I've done an iriver port of this encoder. Sound quality is soso. Speed is about 120% real time (128kBit) on the target with highly optimized code. -- Antonius Hellmann
Could the existing encoder be extracted from iriver firmware and made a plugin for rockbox? Would this violate rockbox's license (GPL)?
Could rockbox call the existing code in the iriver firmware? The code is already there in ROM, it would be like Linux making PC BIOS calls.
You are already hacking the firmware to add a bootloader. This would be just hacking it a bit more
A non-realtime encoder would be acceptable for now. Eg capture .wav and then compress to .mp3 in a batch process later. This can apply to all codecs for which there is no realtime encoder available yet, eg OGG/Vorbis. Why compress inside the player instead of doing it later on a desktop PC or laptop? Well, not everyone wants to lug a PC or laptop out in the field when capturing audio. Compressing it inside the player with rockbox would be very convenient and the quality could potentially be much higher than a realtime encoder because you don't have to cut corners.
We still have the problem that there is no quality integer lossy encoder other than WavPack? lossy (which is already being ported by the developer). Vorbis, Lame and etc. all depend on an FPU. While we could probably emulate an FPU on the ColdFire, speed would be so overwhelmingly slow that you would probably run out of battery before the first track was encoded.
(No need to point out fixed-point libs here, the actual encoder code would be to be adjusted to use fixed-point and it could be done any way you want, using a fixed-point lib or not.)
Q: Would it be possible to use a bridge codec which uses directly the inbuilt hardware encoder for iRiver?
A: The iRiver encoder is not hardware based. It's a software decoder, probably this one. So no, we cannot use that.
This encoder provided by freescale would probably be a clever solution, but that would require that Freescale is willing to allow the RockBox project to use it with reasonable license conditions. That is not likely.
Given the incredible hostility of Fraunhofer and the tons of patent encumbrances around mp3. I don't see why we should reward fraunhofer's misbehavior with promoting their patent-encumbered format, when they'll just turn around and stab you in the back. Can you even legally bundle an mp3 encoder? The patents would seem to point to "no". IMO vorbis is far more worthy of effort (it's a better codec anyway).
Fraunhofer stopped being hostile towards MP3 encoders distributed for free years ago. These days, they only go after people making profit out of MP3 encoding and not paying the licensing fees.
Because they succeeded in shutting most of them down? lame avoided the c&d by distributing purely as patches against dist10. i dont know how gogo avoided it. the rest (bladeenc, 8hz, etc) promptly capitulated on receipt of the c&d letters.
Q: Can you even legally bundle an mp3 encoder? The patents would seem to point to "no".
A: MP3 decoders suffer from pretty much the same patents. If we go that way, we'd have to strip off mp3 decoding as well.
It is best to steer clear of patents, especially when you absolutely know you are infringing. There is nothing better to fuel the anti-opensource argument of "they dont care about infringing on IP" if they can point to actual examples, and I would hate to see rockbox be that example. Surely there are other codecs (if not vorbis then MPC, FLAC, WavPack? or such) which could be integerized and dont infringe patents.
More info on patent licensing http://www.mp3licensing.com/royalty/index.html
If Archos and Iriver paid their liscenses, isnt that good enough for us? (notable exception being the sims)
You mean a patent license is transferable from one product to another? Eg the license for mp3 is transferable from Microsoft Windows 2000 to Linux? Or are you implying the Iriver patent license for mp3 as a 'hardware device' covers anything which might run on the IHP? The latter interpretation would seem more reasonable. If that interpretation legally works then it would clear rockbox.
I guess if Iriver already paid "per unit" price of licensing, then there should be no problem using mp3 feature in rockbox since the use of it is paid. No matter who paid, isn't it?
It is interesting to note that iriver is not listed as a licensee.
I don't think that tells us much. It could instead be the producer of the encoder (some software company) that's listed. JonasHaeggqvist - 25 Aug 2005
It would seem to confirm iriver is not the one paying the patent license fee, and that they just purchased software from a third party.
Either way, I don't know how we could rely on a license fee paid either by iriver or a third-party software company unless we could get a copy of the license agreement to review. -- MichaelDiFebbo - 26 Aug 2005
And if we get a "cease and desist" letter, we can allways do just that, remove the codec. :P -- MarkHawthorne - 26 Aug 2005
If iriver and archos' license can be legally cover the hardware then rockbox may be in the clear. A lawyer would have to look at that though. If the iriver license cant legally cover the decoder, then yes it would be best to scrap the decoder even though that would suck. Doing otherwise could be viewed as unethical.
If we had to drop the mp3 decoder, we could as well scrap the whole project, because an MP3 player which doesn't play MP3... well... sucks.
r3 - 07 Oct 2005 - 16:50:31 - RobertoAmorimRevision r2 - 26 Sep 2005 - 20:09 - AntoniusHellmann
Revision r1 - 19 Sep 2005 - 14:49 - JonasHaeggqvist
Copyright © by the contributing authors.