Open RyanBram opened 9 years ago
I would love to have a built-in mo3 loader (so we could use it with, say, the Android player), but we don't have a royalty-free mp3 decoder to decode the samples.
On Tue, Feb 3, 2015 at 5:41 PM, RyanBram notifications@github.com wrote:
Current libxmp support for mo3 format are by using proprietary mo3 software by Ian Luck. By adopting the opensource version of unmo3 https://github.com/lclevy/unmo3 there will be no need for libxmp to depend on binary bloob by Ian Luck.
I contacted the author to re-license his code to LGPL and he show his intention to do it if there are open source projects which want to adopt his code.
Regards
— Reply to this email directly or view it on GitHub https://github.com/cmatsuoka/libxmp/issues/26.
Hi, Mr. Matsuoka. Thanks for your reply.
Actually mo3 format wasn't exclusive for MP3 codec. The latest mo3 specification allow ogg vorbis to be used as lossy codec .Therefore if we want to avoid patent issue of MP3 format, please use OGG Vorbis as decoder.
Official website Unofficial format specification
Best regards, RyanBram
Note that using the existing unmo3 code would be equal to shooting yourself in your foot. Seriously, DON'T USE IT. It's just a proof of concept and full of things waiting to crash (I am not exaggerating, it is quite easy to crash with invalid input). I'd like to write a new unmo3 decoder from scratch some day (which could potentially be used in libxmp as well), but don't ask me when that day will be. Also, "mo3 not being exclusive for MP3" is no argument. You would be unable to play a large chunk of MO3 files without proper MO3 support and as such it would be largely useless to have a custom implementation.
Hi, Saga. Nice to meet you. I thing my argumet about MP3 codec support still valid. There are many media player outside there which don't support all of features of a container. An example is AVI. As a container, AVI may contain many video and audio codecs, such as DIVX, XVID, Cinepak, Indeo, etc. And it isn't something strange to see many video player which supported AVI, but didn't support all of its codecs. I am searching some rarely mo3 files through internet, and not many of them seem using MP3 codec. Perhaps it is because most of module composers are computer iterate which make them understand about MP3 patent issue and try to avoid it. Supporting only Vorbis at the moment is better than not supporting at all. And I think partial support of an format doesn't mean it as custom implementation.
Cheers
What would be the advantage of a half-working opensource implementation over a fully working binary blob, though?
Being an open source itself is an advantage. And I don't think I need to tell you the advantages of it (the ability to distribute, study, modify, make derivative work, etc) because you are also one of the biggest contributor in FLOS Software.
Supporting only vorbis format is not half working. Half working is if a library only capable of playing 30 seconds of 1 minute MO3 file. I dont't think converting MP3 sampled MO3 to Vorbis sampled MO3 as a big task, because there is available free tools for do the job and the number of MO3 format around internet is very small compared to other module formats.
Please note that, my suggestion about vorbis only support is for avoiding MP3 patent which may hamper the development of opensource MO3 decoder, not because I have purpose for it. I am really sure that an expert programmer like you can easily make a dynamically linked MP3 library or provide an option to disable MP3 support in build options therefore users can choose if MP3 support is needed or not for them. But I need to admit that you are the winner here, as I am just a amateur musician and you are a pro programmer.
Regards, Ryan
I am of course aware of the greatness that is open source, however I don't see an advantage to you, the user, if you can choose between a half-working open-source and fully-working closed-source implementation, that is my main point and my main lack of motivation of writing a full MO3 decoder (though Claudio could think differently of course, I'm just talking from the perspective of a (lib)openmpt developer). Unless you strongly believe in open-source and only touch things that are FOSS-approved, I think there's not much to gain from such an implementation.
Ok, I hope the following argument is reasonable enough to give you motivation: Why mo3 format is not so much widespread eventhough it offer some advantage over other modules such as IT? The reason is 2:
License issue Eventhough someone has paid that much money, he still doesn't retain full right of the product as the license only allowed per platform basis, which meen he need to pay more if he want to support Mac, Linux, Android, iOS, etc
To make it worst, the license only permitting someone for creating end user product which make its very hard to be integrated as integral part of multimedia framework, such as Qt, GStreamer, SDL2, etc. Then it will resulting the following impact:
I will prefer to spend money to support open source library which has partial support of M03 format than paying 3450 euro to fully functional MO3 library which I have no full right of it. Because replacing MP3 to Vorbis is just a piece of cake comparing to pay money that much which only benefit to me and not the others.
wow.
Finally, Saga Musix has implemented opensource native M03 decoder in OpenMPT software. I hope XMP developer can adapt it into XMP.
Thank you for your consideration.
Current libxmp support for mo3 format are using proprietary mo3 software by Ian Luck. By adopting the opensource version of unmo3 there will be no need for libxmp to depend on binary bloob by Ian Luck.
I contacted the author (Laurent Clévy ) to re-license his code to LGPL and he show his intention to do it if there are open source projects which want to adopt his code.
If libxmp developers want to use the opensource version of unmo3, please let me know. I'll contact the author immediately for relicensing his code. Please note that I am not a programmer, therefore the only thing that I can help is by giving connection for this project to unmo3 project by Laurent Clévy.
Regards