Skip to main content ↑ ↓

Notice

Please note that most of the software linked on this forum is likely to be safe to use. If you are unsure, feel free to ask in the relevant topics, or send a private message to an administrator or moderator. To help curb the problems of false positives, or in the event that you do find actual malware, you can contribute through the article linked here.
Topic: Portable possibilty for MPC (Read 14852 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Portable possibilty for MPC

Reply #25 –
Just had a glance through the integer source decoder... the only copyright stuff i can spot is by the START GROUP

bitstream.h
bitstream.s
SynthCalSample.s

Seem to mention this, the latter being the most detailed

Quote
; SYNTHCALSAMPLE.S - perform synthesis of subband samples(ISO-11172-3).
;
; Copyright © 2000 START GROUP.


What are the START group.. is this the only patent issue involved with MPC.. the whole subband related stuff, is that ISO the only relevant one that is involved?!? As i asked earlier (did I?) is it enough for hardware manufacturers to just have a decoder that is copyright/patent free or does the whole package have to be cleared?!

Portable possibilty for MPC

Reply #26 –
http://freevo.sourceforge.net/mp3/Lagerstr..._MP3_Thesis.pdf

describes this ISO as

"The ISO standard 11172-3 MPEG-1 layer III (a.k.a. MP3) is a perceptual codec that is presently very common for compression of CD quality music."

so is this ISO only concerned with MP3.. i guess there must be more patents than this in MPC?! Lets for a moment assume there wasn't and it was just this one... would payment for mp3 cover the use of this for other formats!??

Portable possibilty for MPC

Reply #27 –
ahh ok, further in it becomes clear..

Quote
The international standard ISO 11172-3 ([2]) defines three different methods of increasing complexity and compression efficiency for perceptual coding of generic audio such as speech and music signals. This thesis deals exclusively with the third method, also known as MP3.


I guess this ISO is just the whole MPEG thing?!? would love to read it.. still googling

...

Result

Quote
ISO/IEC 11 172-3, “Information technology - Coding of moving pictures and associated audio for digital storage media at up to about 1,5 Mbit/s - Part 3: Audio,” first edition, Aug. 1993.


That should help.. its obviously quite huge, only concerned with audio but still..

Portable possibilty for MPC

Reply #28 –
Please read these topics concerning patent issues in MPC:

http://www.hydrogenaudio.org/forums/index....showtopic=10072
http://www.hydrogenaudio.org/forums/index.php?showtopic=8585
http://www.hydrogenaudio.org/forums/index.php?showtopic=2910
http://www.hydrogenaudio.org/forums/index.php?showtopic=1840
http://www.hydrogenaudio.org/forums/index.php?showtopic=2899

The last one specifically covers the possible patent issues in detail straight from Frank Klemm, the MPC developer.  The bits from him and Garf are the most telling.

Portable possibilty for MPC

Reply #30 –
Quote
What are the START group.. is this the only patent issue involved with MPC..

That is a copyright, not a patent.

And that copyright doesn't means much. It means the code is owned by the START group, but since that code is LGPLd, it makes no difference, really.

Portable possibilty for MPC

Reply #31 –
Quote
Quote
QUOTE 
Originally posted by Dibrom


Assuming this is correct, does this mean that it's possible that MPC could be patent free? If not, perhaps because of legacy MP2 code/technology/etc, could it be made to be patent free without too much trouble?


Frank Klemm said

*No, at least not SV1...SV8.
*Philips subband patent can be removed, but
- this would significantly increase CPU load of decoder
- increase significantly latency
- then I would not use an equidistant subband filter



Is this the crux of it!?? there is some subband patent code.. thats it... its currently in there, and will remain in there... SV8 is included in that so SV8 wont be patent free, at least that wasn't the direction back then?!

I guess when we are talking about trying to get this thing working in hardware you are wanting to make it as cheap (processor-wise) as possible... this subband component appears to not really effect encoding at all (~3% i believe i read), but counts for ~40% of decoding.. something that would get slower to be patent free

I dont fully grasp what latency is being discussed above, nor the equidistant subband filter.. I guess it means subbands would vary in size, is this a bad thing for transparency!? after all this is what MPC is about..

I read elsewhere in there

Quote
I don't think it is an patent issue. Originally it was planed to
* have a open source decoder
* closed source encoder
* pay patent fee
* for mppenc usage

problem was to sign a patent contract.
Ask Andree for more details.


This sounds great I am sure if this fee was small we'd all easily want to contribute.. its just seems strange that if the one patent issue is so intertwined with decoding how could the patent only apply for encoding...

Anyways this doesn't really sound like something that is a priority right now, nor something that is going to change in the future.. this is just one patent issue but i trust the investigations made in the posts above that this is 95% accurate that its the only patent issue in the whole of MPC... I fear that given the response from Rio above regarding patents/licenses etc.. they would not go any further with serious MPC support until these issues were resolved..

Is Frank still online reading these things, have you any thoughts!?!? is hardware playback even something that Frank is interested in happening, with this device or any other?! would you be interested in discussing this with the rio guys after they ship their product and may have time to talk it through!? Is Andree still involved, and what are his thoughts on this!??

Is MPC opensource yet!? is their a timeline on this, that other thread that announced up and coming open source MPC is nearly 8 months old.. I know being opensource would help MPC support being added to hardware by just letting it all be there for anyone to look over for any legal issues but it wont be enough in this case to persuade Rio, although it may at least bring it one step closer..

Portable possibilty for MPC

Reply #32 –
Read those posts again. First, noone knows if it's really patented, that is a belief of Andree (original MPC developer) that got widespread without any serious base.

Second, if it's really patented, noone knows if the patents will be enforced. Specially, if patents are to be enforced, they would probably only be enforced on encoders, what leave decoders (whether on hardware or wherever) off the hook.

Heck, noone even knows who would enforce these patents! (I.E, noone knows who owns them. Philips? Sisvel? ...)

Quote
Is MPC opensource yet!? is their a timeline on this, that other thread that announced up and coming open source MPC is nearly 8 months old.. I know being opensource would help MPC support being added to hardware by just letting it all be there for anyone to look over for any legal issues but it wont be enough in this case to persuade Rio, although it may at least bring it one step closer..


How can you be so much into advocating MPC without even getting informed first? >_<

*SV8 is already open source and will always be (?), but it's not usable yet for purposes other than testing.

*SV7 is closed source. Frank said sources would probably get opened in 2004, still related to some of the vague patenting stuff, but nothing new has been announced since then.

Portable possibilty for MPC

Reply #33 –
Somewhere in those threads you can basically come to the conclusion (which Garf seemed to support), that there is only 1 patent that might seriously affect MPC.  The problem is that neither Frank nor Garf could actually verify that this patent existed!  The information that this patent was an issue came from the original MPC author who has long since left the community.  He contacted the company that supposedly held the supposed patent (heh), but they were uninterested in collecting royalties.  Since then, Garf and Frank have not been able to verify the existance of this patent or even have an idea of who might hold it.

I think the bottom line here is that it's simply not an issue then.  Given the obscurity of the patent (if it even is an issue), and the obscurity of the company that must hold it, and the fact that nobody has ever shown a single bit of interest at all in collecting any royalties, I think it's safe to say that there should be no problem here.  MPC will never have a wide enough userbase to change any of this either, and that's not even considering the fact that the patent has likely already expired or will expire soon.

I personally don't think you're going to get a more definitive or formal response to this situation either, so if the company is unwilling to add support at this point, I doubt that will ever change.

Portable possibilty for MPC

Reply #34 –
Quote
*SV7 is closed source. Frank said sources would probably get opened in 2004, still related to some of the vague patenting stuff, but nothing new has been announced since then.

I don't think it had anything to do with patenting, but rather that he expected SV8 to be live by then, and if not, he'd just open the sources to SV7 anyway.

Portable possibilty for MPC

Reply #35 –
Sisvel now holds most MPEG patents, and despite being quite obscure a year ago, they've become a bit more prolific with a new website (audiompeg.com). However, I already checked it, and the patent list in there doesn't contain the patent that was questioned.

As I understand, MPC's main safety is that most of the core technology is already so old that they have expired. This may have been the case as well, which could be why it can't be licensed.

But I really dislike this uncertainty. A full MPC patent search would be interesting, but needs someone to pay for it. Alternatively someone very intimate with the code could spend a lot of time doing a manual patent search, which would already give a firm indication of the status.

Portable possibilty for MPC

Reply #36 –
Quote
How can you be so much into advocating MPC without even getting informed first?


I don't know... I've used MPC for 3 years now perhaps... I've always been very impressed by it.. I'm not so much advocating MPC as really wanting to try and see if we can get some hardware support... vaguely knowing some people who could make this a possible reality I am just trying to find out as much information as i can relating to the fears that i know they have at the moment..

In all that time tho i have never yet tested SV8.. i am fairly busy and to be honest my MPC collection has faded away a little.. most of my CDs are all encoded up, in fact some have had to be deleted as i struggle with diskspace... getting an mp3 jukebox has also restricted most of my audio encoding when i get chance to doing lame encodes ready for that.. sorry i am out of touch with it all.. I just wanted to clarify some points (the opensource one).. I do try to read HA regularly but HA is a very fast moving forum and inevitably a lot gets through in my downtime away from the forum..

These last sets of posts really help me to sit quite confident with the state of MPC as far as any patent/legal issues with it, but i really do agree fully with Garf

Quote
But I really dislike this uncertainty. A full MPC patent search would be interesting, but needs someone to pay for it. Alternatively someone very intimate with the code could spend a lot of time doing a manual patent search, which would already give a firm indication of the status.


It is this very uncertainty that is going to hold it back for now in this case.. after me talking above about not having time, i can totally understand why this isn't happening... at least a manual patent search sounds a bit cheaper.. cause we dont have the money either do we...

I dont want to push the conversation that I am having with Rio on this, its nice to have any communication at all with someone who could basically make all this a reality.. I am now more informed (tho still obviously not as informed as all you guys) on this subject and will try to get most of these points back to Rio when I next talk with them.

Thanks a lot for everyones help, searches to find old forum links, and effort... at least this thread (aside from the silly mpc is crap below quality 10 near the start) is now a great collection of nearly everything concerned with all of this..

Portable possibilty for MPC

Reply #37 –
Ok well I emailed him last night just asking him a little more about the worries he spoke of, and also asking how easy he thinks it would be to plug into their engine.. just got a fairly exciting response.. I've not even updated him with what people discussed last night regarding the exacts of the patent issue (especially in that no one can actually find the patent in question that was announced by Andree a long time ago)

I will get in touch with him later on informing him on this... for now other peoples responses to this would be appreciated... he managed to download the decoder even tho to me those links are dead.. the copyrights he speaks of.. i am not at home with those files atm so i dont know if that is the same as what i found and posted about above...

Quote
Yes, danger as in copyrights and licenses. See some of the .S files, which
appear to be taken from a totally different project and are copyright a
random company somewhere (DCT code, ISTR).


Quote
To integrate into our framework nicely, we need this in general from a
codec:

- No dynamic memory allocations. We pass it a pointer to an amount of
workspace irt requires (eg, MP3 requires 20k) which we put in internal
static RAM which is zero-wait-state and full core speed.

- We then call it with encoded data (after syncing to the bitstream) and
expect it to produce output buffers - either interleaved or noninterleaved
is fine. MPC appears to behave like MP3 here (1152 samples per frame).

- It needs to provide a way to seek to a millisecond offset in the file (or
nearest frame)

- It needs to provide information on the file (sample rate, mono/stereo) so
we can feed this to our resampler.

- We need to have a set of good/bad test files for QA.

Those are the main points I think.


Quote
If it went in really cleanly and with little hassle then there's a good
chance that we could slip it into a future release without bothering too
many people, like we did with OGG (though OGG wasn't a clean integration job
by any means... lots of dynamic memory allocation and bursty CPU demands.
FLAC was much easier).


This is BEFORE he's read that the patents are less of an issue than the files he's looking at suggests... and he's talking about possibly being able to slip this in... seriously i think this is the best chance we've got.. I am a programmer but have zero audio coding experience, but i would be prepared to try and help if i could at all... If the file and copyright he is talking about above IS the one i found before that rjamorim said was LGPLd then could we replace it with one or get the documentation to support that and add it into the archive... This just feels so close and on some hardware that is coming to the west in a form that without MPC support is still very appealling... can we transform the fixed point decoder to conform with the above requirements... is replaygain and dithering something that can be added so that its delievered to Rio in a form that is more final to people who would want to use it!? I guess the whole APE tagging stuff would be required to be done in another part of their engine but its quite a clean thing...

How close is the current fixed point decoder to the standard decoder, do the MPC developers feel at home within it or has it had to be changed significantly to be fixed point!?

Just too good... I just wish i had the knowledge to help  anyone else have the know how and would like to try??

Portable possibilty for MPC

Reply #38 –
actually just looked... I doubt they'd be too interested in replaygain straight away as they have their other gain management thing which i guess they'd want to try and sell, tho the consensus on that is that its poor for all but noisy environments (it is a portable after all i guess)

and if this ever did happen i am sure so long as the specs werent broken newer features could be added.. I'm curious why they would want to get access to info for a resampler, unless its like a SBLIVE and can only output 48khz etc... shame if its so.. tho my current jukebox3 suffers from this and i'm not too bothered

Portable possibilty for MPC

Reply #39 –
Quote
If the file and copyright he is talking about above IS the one i found before that rjamorim said was LGPLd then could we replace it with one or get the documentation to support that and add it into the archive...

OK, you guys didn't understand it, but I don't blame you, since the GPL and LGPL are some messy POS.

Anyway, the .s code was based on LGPLd code. That means that, even though this START group has the copyright, anyone can use this code without having to report to them. Just take the code and use it whatever way you like. The only catch of the LGPL is that if you make changes to the code of that library, you must make these changes public. (although I doubt anyone would try to enforce it on the Rio manufacturer)

Hope it helped;

Roberto.

Portable possibilty for MPC

Reply #40 –
Quote
Just take the code and use it whatever way you like. The only catch of the LGPL is that if you make changes to the code of that library, you must make these changes public.

The (L)GPL is a bit more sophisticated than that  If you use GPLed code and distribute it in your work, the terms of the GPL apply to the entire work, and you must offer the source code to it. If you used LGPLed code in your work, the source code for the LGPLed code must be offered, and it must be possible to change the LGPLed code with another copy. Of course, I am not a lawyer, so I'm probably quite wrong

This is why I don't use either for what I write...

Portable possibilty for MPC

Reply #41 –
Thanks for the info on GPL, LGPL or whatever.. no i am not very fluent with it all.. I kinda knew it was similar to opensource, well there was source available..

Is anyone else really excited about this tho, or is it just me... this really does feel like it may be possible... I would love some input from Frank Klemm... are you there?!

Portable possibilty for MPC

Reply #42 –
Quote
If you used LGPLed code in your work, the source code for the LGPLed code must be offered, and it must be possible to change the LGPLed code with another copy


So you simply just have to ship these copyrighted source files out with stuff!!? the thing is firmware for these devices i dunno.. dont usually come with source  I will pass on all of this stuff at some point... but i doubt i'll hear from him till next week, being the weekend and all..

Still no replies at all regarding anyone being able to help shape the decoder to meet the Rio requirements, or enhance it to include dithering... is the dithering even that important.. few people can hear it!? (few as in those without golden ears, which sadly i've come to realise [following the difficulties with the 128k listening test] includes me)

Quote
- No dynamic memory allocations. We pass it a pointer to an amount of
workspace irt requires (eg, MP3 requires 20k) which we put in internal
static RAM which is zero-wait-state and full core speed.


Does anyone know if the decoder as is already passes this... if so how much memory is required.. how many buffers does MPC use, I assume this isn't just the output buffer?!?

case IOCTL_CODEC_SETBUFFER:

allocates that, but i dont know if its the only allocs thats going to happen

Quote
- We then call it with encoded data (after syncing to the bitstream) and
expect it to produce output buffers - either interleaved or noninterleaved
is fine. MPC appears to behave like MP3 here (1152 samples per frame).


I've looked at the main entrypoint (MPPIoctl() in MPCdecoder.c) in the decoder and it seems to have the switch statement for all the different tasks.. i'll look again but somewhere it must do something like this, or does the decoder at the moment try to manage all forms of the reading of the files..

well it appears it does

case IOCTL_CODEC_OPEN:

has basic file pointer management, checking extensions etc..

Quote
- It needs to provide a way to seek to a millisecond offset in the file (or
nearest frame)


There is another case..

case IOCTL_CODEC_SEEK:

that i assume will do something like this but isn't implemented and at the moment just fails

Quote
- It needs to provide information on the file (sample rate, mono/stereo) so
we can feed this to our resampler.


case IOCTL_CODEC_GETSAMPLERATE:
case IOCTL_CODEC_GETCHANNELS:     

takes care of this... we pass

Quote
- We need to have a set of good/bad test files for QA.


I am sure we would have no trouble providing good files, would the developers be able to find/create various bad test files

So from what i can see only the

dynamic memory allocation,
working on encoded data, not opening files
seeking,

are things that are not OK at the moment.. does anyone else know anything that can perhaps take care of whether the decoder works with a fixed buffer, with no dynamic memory allocation...

Portable possibilty for MPC

Reply #43 –
To settle this once and for all, who would be interested in donating a small amount each to a paypal account to fund a patent search? I'd do it. How much do these things cost?

Portable possibilty for MPC

Reply #45 –
Quote
So you simply just have to ship these copyrighted source files out with stuff!!?

No. You just have to make these sources available, no matter how. You can ship your product with the sources, indeed, but you can also put a link at your web page for downlod, or send a floppy with the sources to anyone who requests them (and, in that case, charging a small fee for media + S&H is accepted), send them by e-mail...

Point is, if someone requests access to the sources, you must make them available somehow.

Portable possibilty for MPC

Reply #46 –
Technically, I believe you only have to make the sources available if you modify them.  I doubt that they could be used completely unmodified though.  From posts on the slashdot thread about the karma, it sounds like at least some of its developers are OSS guys and understand the GPL and LGPL (which is why they added vorbis support in the first place.)

Either way, I doubt it will upset to many rio shareholders to distribute the decoding source for a fringe codec for which decoder source is already available.  If it is LGPL, they wouldn't have to open up their whole firmware or anything.

As far as the patent search issue goes, I'm willing to donate (though I don't have tons of loose cash lying around.)
I am *expanding!*  It is so much *squishy* to *smell* you!  *Campers* are the best!  I have *anticipation* and then what?  Better parties in *the middle* for sure.
http://www.phong.org/

Portable possibilty for MPC

Reply #47 –
Quote
Technically, I believe you only have to make the sources available if you modify them.

Well, I understand you have to make sources available anyway, if you don't modify them, you just have to point people to the original sources.


I believe a through patent search would cost you guys some thousand dollars. You'll need to contract a patent specialist lawyer, a technician that understands the algorithms and translates them to legalese, probably a format developer will have to get involved...

Portable possibilty for MPC

Reply #48 –
Quote
I believe a through patent search would cost you guys some thousand dollars. You'll need to contract a patent specialist lawyer, a technician that understands the algorithms and translates them to legalese, probably a format developer will have to get involved...


aha well thats 2/3 of us so far  i guess we're going to come up short.. they may be less concerned about patents when i tell them about the LGPL stuff.. still no reply from Frank, isn't he very active on these forums anymore?!?

Portable possibilty for MPC

Reply #49 –
Quote
they may be less concerned about patents when i tell them about the LGPL stuff..

man, for God's sake, get informed before you make assumptions!

LGPL and GPL have nothing to do with patents! You can easily have LGPL/GPL'd code that is patented. Look at Lame, Faac/Faad, XviD, hdot264...

GPL and LGL are simply licenses that force you to keep source code open, and don't allow you to close them and hide them away. They also guarantee anyone can use the code in their own projects given they abide to the license terms, without having to get permission from the copiright owners.

They don't interfere with patents, copyrights or file permissions :-P

Quote
still no reply from Frank, isn't he very active on these forums anymore?!?


He kinda stopped posting after I called him an Ass.