IPB

Welcome Guest ( Log In | Register )

2 Pages V   1 2 >  
Reply to this topicStart new topic
working around MP3 patents, what features do specific patents refer to
bawjaws
post Mar 16 2012, 13:25
Post #1





Group: Members
Posts: 173
Joined: 10-December 02
Member No.: 4043



I've been reading some of the mp3 patents and it appears to me (as someone with no general legal experience, no deep knowledge of patents, or great understanding of the inner workings of mp3) that some of them could be worked around easily if you cared more about avoiding patents than you did about making full use of the specification. And since many of the patents are expiring already a workable patent-free subset may already, or soon, be possible even before the very final patent expires around 2017.

To give a simple example, one of the last patents to go (according to http://www.osnews.com/story/24954/US_Paten..._MPEG-2_H_264/) is US patent 5812672:

"Method for reducing data in the transmission and/or storage of digital signals of several dependent channels"
http://patft1.uspto.gov/netacgi/nph-Parser...tnumber=5812672

This seems to be a patent on the concept of switching between different joint stereo modes based on the audio content. So a simple workaround would be to only produce mono files. No stereo means no joint stereo, means no switching between joint stereo modes, means absolutely no possible infringement of this particular patent (and if your intended input or output format was mono in the first place, absolutely no loss in quality compared with patented methods). If similar could be done for each of the remaining 12 (according to the link above) patents then you could include such an encoder in F/free software, and distribute mp3s created with such an encoder in games or in streaming radio without paying any fees and have them decoded by any standard-compliant decoder.

Note that I think for the example above, you could easily have stereo files without infringing the patent as long as you only had one stereo mode per file but I went with the mono example because it makes the non-infringement clearer. Maybe you could be very sneaky and still switch modes as long as you did it in a very slightly different manner from that described in the patent and get some further improvment in quality as a result. For all I know, maybe lame already does this differently/better than the patent. But that's just icing on the cake. Having *anything* that produces compatible mp3 files, even at a cost of reduced quality or flexibility would be a start and be useful to *someone* since mp3 is generally used today for compatability reasons rather than because of its technical qualities.

I'd like to know if there has been any concerted effort by people who actually understand this stuff (on both the legal and technical side) to create a functioning mp3 encoder and/or decoder that works around all known patents. Is it possible? At what cost in functionality, quality, bitrate etc. If not, which particular patent(s) are the blockers which you can't possibly work around and without which you cannot have a compatible, non-ear-killing mp3 and when does the last of them expire?

(There's also the interesting sub-issue, which seems to apply to most modern lossy codecs, which is if your encoder is doing something incredibly clever (and/or patented) to decide when to switch between different encoding modes, but your decoder is dumb as a rock and simply does what the encoded file tells it to, does the patent for the encoder process have any impact on the decoder?)

I'm guessing the messed up nature of patents means no-one with an actual business to protect is going to want to risk this when there are feasible alternatives (e.g. pay the fees or use vorbis) but it seems like it might be an interesting intellectual excercise anyway and some free audio tools (e.g. Audacity) might include such a thing if the general consensus was that it was possible (just as some people would avoid Vorbis because "you can never be sure" about patents, but it hasn't stopped most reasonable people).

This post has been edited by bawjaws: Mar 16 2012, 13:29
Go to the top of the page
+Quote Post
bawjaws
post Mar 16 2012, 16:39
Post #2





Group: Members
Posts: 173
Joined: 10-December 02
Member No.: 4043



So, now you've got the general idea, some patents in reverse order of expiry (last to expire listed first):

Patent: Method and apparatus for encoding digital signals employing bit allocation using combinations of different threshold models to achieve desired bit rates
http://patft1.uspto.gov/netacgi/nph-Parser...tnumber=6009399
My uninformed take: use of multiple psycho-acoustic models, choosing most appropriate one based on targetted bitrate
Workaround: use the cited prior art which uses a single psycho-acoustic model but simply moves it up and down linearly to use up the correct amount of bits

Patent: Process of low sampling rate digital encoding of audio signals
http://patft1.uspto.gov/netacgi/nph-Parser...tnumber=6185539
My uninformed take: seems like a tweak in MPEG 2 layer III that repurposes MPEG 1 layer III to use three lower sample rates which are half the original spec (24, 22 & 16 added to 48,44 & 32 Hz)
Workaround: don't use those lower sample rates

Patent: Method for reducing data in the transmission and/or storage of digital signals of several dependent channels
http://patft1.uspto.gov/netacgi/nph-Parser...tnumber=5812672
My uninformed take: discussed in the first post, switching between joint stereo modes based on audio content
Workaround: Use Mono, Dual Stereo or Mid-Side for the whole file

If those three workarounds stand up then you've brought patent free mp3 forward almost exactly two years from April 2017 to April 2015. Then it gets tricky:

Patent: Digital adaptive transformation coding method
My uninformed take: No idea
http://patft1.uspto.gov/netacgi/nph-Parser...tnumber=5742735
Workaround: No idea

But since it gets easier again in the next one, I'm hopeful someone who actually understands what that patent means will see an easy workaround too.

Patent: Method for determining the type of coding to be selected for coding at least two signals
My uninformed take: an automatic way to choose when intensity stereo would be a good idea
http://patft1.uspto.gov/netacgi/nph-Parser...tnumber=5736943
Workaround: don't use intensity stereo ever, or let the user specify whether to use it or not

Patent: Method of coding a plurality of audio signals
http://patft1.uspto.gov/netacgi/nph-Parser...tnumber=5701346
My uninformed take: for encoding multi-channel surround sound
Workaround: only support stereo

Patent: Process for transmitting and/or storing digital signals of multiple channels
http://patft1.uspto.gov/netacgi/nph-Parser...tnumber=5706309
My uninformed take: for encoding multi-channel surround or multiple audio tracks like DVD commentaries
Workaround: only support stereo

etc. You get the idea. 6 out of 7 of these seem laughably easy to workaround (as long as you're not trying to encode multi-channel audio), and there's only 12 in total. So I'm guessing either I'm totally wrong about patents or law or encoding or there's some real doozies hiding in there that make it irrelevant to workaround the easy ones. Maybe the one that I don't understand is that doozie, but can anyone say for sure?

This post has been edited by bawjaws: Mar 16 2012, 17:03
Go to the top of the page
+Quote Post
saratoga
post Mar 16 2012, 19:12
Post #3





Group: Members
Posts: 4907
Joined: 2-September 02
Member No.: 3264



QUOTE (bawjaws @ Mar 16 2012, 10:39) *
Maybe the one that I don't understand is that doozie, but can anyone say for sure?


I think claims 1-3 are basically for the quantization and scale factor system used in mp3. I don't think you could work around that while retaining compatibility with the standard.
Go to the top of the page
+Quote Post
ZinCh
post Mar 17 2012, 05:54
Post #4





Group: Members
Posts: 171
Joined: 28-September 06
Member No.: 35705



this is US patents. is there any patents for MP3 in other countries?
Go to the top of the page
+Quote Post
bawjaws
post Mar 19 2012, 15:09
Post #5





Group: Members
Posts: 173
Joined: 10-December 02
Member No.: 4043



QUOTE (ZinCh @ Mar 16 2012, 21:54) *
this is US patents. is there any patents for MP3 in other countries?


The Thomson ones have the various countries that each patent is registered in on their page:

http://mp3licensing.com/patents/index.html

Slightly bizarrely, the table is an image so hard to search but all of the patents I've listed above seem to be there for the US, the EU and a smattering of other countries e.g. TW and JP. There's some that don't have a US patent number too.

Go to the top of the page
+Quote Post
bawjaws
post Mar 19 2012, 16:24
Post #6





Group: Members
Posts: 173
Joined: 10-December 02
Member No.: 4043



QUOTE (saratoga @ Mar 16 2012, 11:12) *
QUOTE (bawjaws @ Mar 16 2012, 10:39) *
Maybe the one that I don't understand is that doozie, but can anyone say for sure?


I think claims 1-3 are basically for the quantization and scale factor system used in mp3. I don't think you could work around that while retaining compatibility with the standard.


A lot of that stuff (quantizing each sub-band to different degrees) seems to be covered by the first two patents cited as prior art (from 1975 and 1980!) so I think it would take a high degree of domain and legal expertise to tease out exactly what new stuff there is here to be protected.

However, I've read that you need to do *everything* in a claim in order to infringe it. If so this claim doesn't seem to be written in a particularly watertight manner. A nobbled mp3 encoder could just fail to do the final step: "if available after the preceding step, any additional number of bits are assigned to the individual frequency groups in correspondence to the quantitized maximum value occurring in the particular frequency group." (or to sail closer to the wind do it slightly differently).
Go to the top of the page
+Quote Post
2Bdecided
post Mar 19 2012, 19:13
Post #7


ReplayGain developer


Group: Developer
Posts: 5089
Joined: 5-November 01
From: Yorkshire, UK
Member No.: 409



L3Enc was released in July 1994...
http://en.wikipedia.org/wiki/MP3#Going_public
...so it would be interesting to know which techniques were used by that encoder.

I wonder how any patents filed after this date justify themselves, unless they're covering newer techniques that L3Enc didn't include?

EDIT: Oh...
http://en.wikipedia.org/wiki/MP3#Licensing_and_patent_issues

Cheers,
David.

This post has been edited by 2Bdecided: Mar 19 2012, 19:17
Go to the top of the page
+Quote Post
Garf
post Mar 19 2012, 19:57
Post #8


Server Admin


Group: Admin
Posts: 4884
Joined: 24-September 01
Member No.: 13



QUOTE (saratoga @ Mar 16 2012, 19:12) *
QUOTE (bawjaws @ Mar 16 2012, 10:39) *
Maybe the one that I don't understand is that doozie, but can anyone say for sure?


I think claims 1-3 are basically for the quantization and scale factor system used in mp3. I don't think you could work around that while retaining compatibility with the standard.


Reading the claims, I don't think this is the case for (1), the analysis of the original poster is correct that this is just one way to handle the bitrate vs distortion issue. This should be workable around, pretty easily in fact.

(2) is trickier, I wouldn't want to make a judgement without a careful rereading of the MP3 format spec. Understanding why this talks about low bit-rates - and how the spec differs there, would help.

(3) is indeed patenting a whole load of methods for M/S switching - this can be worked around easily, maybe at the loss of some efficiency.

(4) USPTO 5,742,735 initially looks like a killer, but as far as I understand patent law the claims have to match up exactly. At some point it says: "in view of psycho-acoustic aspects, quantification noise is masked for that frequency group; and if available after the preceding step, any additional number of bits are assigned to the individual frequency groups in correspondence to the quantitized maximum value occurring in the particular frequency group." The latter part makes this, IMHO, easily avoidable.

I haven't looked at the others yet.
Go to the top of the page
+Quote Post
DVDdoug
post Mar 19 2012, 21:35
Post #9





Group: Members
Posts: 2565
Joined: 24-August 07
From: Silicon Valley
Member No.: 46454



If you try to get around the patents, but make something that's MP3 compatible, you are probably going to get sued (if you distribute the CODEC). Even if you win in court, your legal bills will be more than just paying royalties... Unless you are an unemployed lawyer with lots of free-time to defend yourself biggrin.gif

If it doesn't have to be MP3 compatible, there's Ogg-Vorbis.

This post has been edited by DVDdoug: Mar 19 2012, 21:42
Go to the top of the page
+Quote Post
Garf
post Mar 20 2012, 07:47
Post #10


Server Admin


Group: Admin
Posts: 4884
Joined: 24-September 01
Member No.: 13



You certainly aren't going to make any patent holder happy if you do this. Should you succumb to mafia-like practices and pay protection money? Probably not.

Anyway, how does this relate to decoders? Most if not all of the patents quoted relate to encoder side decisions.
Go to the top of the page
+Quote Post
Garf
post Mar 20 2012, 11:41
Post #11


Server Admin


Group: Admin
Posts: 4884
Joined: 24-September 01
Member No.: 13



I found several other lists of patents, including the ones you didn't list, put them in a table, and read through the claims of all of them. I'm not sure all of the expiration dates are correct, this is tricky to determine.

Based on what I know of the MP3 standard, writing a patent free encoder should be possible the 24th of September 2013, but not before that. I am not so sure about a decoder, as many patents describe systems consisting both of encoders and decoders. How can decoders guarantee the encoder didn't use a certain technique? Additionally, there is one patent that I believe the encoder can avoid, but a standards compliant decoder wouldn't.

Someone who's even more familiar with the MP3 spec can probably confirm/deny/correct some of these.

Summary:
https://docs.google.com/spreadsheet/ccc?key...ZGxWeTlYUlpxS2c
Go to the top of the page
+Quote Post
.alexander.
post Mar 20 2012, 11:54
Post #12





Group: Members
Posts: 73
Joined: 14-December 06
Member No.: 38681



Graf, if it's not too much of trouble could you create a list of AAC related patents as well?
EDIT: just figured out that you provide sources in your summary.

This post has been edited by .alexander.: Mar 20 2012, 12:02
Go to the top of the page
+Quote Post
Garf
post Mar 20 2012, 13:04
Post #13


Server Admin


Group: Admin
Posts: 4884
Joined: 24-September 01
Member No.: 13



QUOTE (.alexander. @ Mar 20 2012, 11:54) *
Graf, if it's not too much of trouble could you create a list of AAC related patents as well?
EDIT: just figured out that you provide sources in your summary.


Getting a list of all applicable patents to MPEG-2 AAC would be a start. The sources I quoted don't seem to actually have them, as they list the patents from MPEG-LA, but the audio parts are being licensed by Via Licensing. Via's site also doesn't list the patents they license (so they don't tell you what they actually sell you? heh!).

From that list, one could then start culling the expired ones, cull everything that isn't necessary for AAC LC, etc. But we'd need a list to start with, and that already seems to be hard to find.
Go to the top of the page
+Quote Post
.alexander.
post Mar 20 2012, 13:30
Post #14





Group: Members
Posts: 73
Joined: 14-December 06
Member No.: 38681



http://www.google.com/search?q=%22MPEG-2+A...tbo=1&hl=en
Go to the top of the page
+Quote Post
Garf
post Mar 20 2012, 14:14
Post #15


Server Admin


Group: Admin
Posts: 4884
Joined: 24-September 01
Member No.: 13



QUOTE (.alexander. @ Mar 20 2012, 13:30) *


Way too much collateral (and no guarantee no essential patents are missing). Seriously, reading through 15 patents and trying to figure if they're essential is doable. Wading through 1000 isn't.

I'm still not clear on what USPTO 5384811 covers exactly, so I'm glad it's expired.

I've made a LAME build which avoids USPTO 5559834. It's usable, though there are severe quality impacts. Still, if you want to make a patent-free MP3 encoder and are willing to accept severe quality compromises, it seems this is possible already today.
Go to the top of the page
+Quote Post
bawjaws
post Mar 20 2012, 22:03
Post #16





Group: Members
Posts: 173
Joined: 10-December 02
Member No.: 4043



QUOTE (Garf @ Mar 20 2012, 06:14) *
I've made a LAME build which avoids USPTO 5559834. It's usable, though there are severe quality impacts. Still, if you want to make a patent-free MP3 encoder and are willing to accept severe quality compromises, it seems this is possible already today.


That's very cool. Is there a public source repository or even just some mp3 samples of its output available?

I wonder if sounding a bit 'odd' would be helpful in avoiding patent troubles since you'd be doing something tangibly different, whereas there's probably workarounds that are technically different but legally murky just because the output sounds the same (or even better) than "standard" mp3.
Go to the top of the page
+Quote Post
Garf
post Mar 21 2012, 11:49
Post #17


Server Admin


Group: Admin
Posts: 4884
Joined: 24-September 01
Member No.: 13



QUOTE (bawjaws @ Mar 20 2012, 22:03) *
That's very cool. Is there a public source repository or even just some mp3 samples of its output available?


Take the latest LAME source and edit newmdct.c where it says "Perform aliasing reduction butterfly". The code suggests that running in all-short-blocks mode also avoids the patent.

QUOTE
I wonder if sounding a bit 'odd' would be helpful in avoiding patent troubles since you'd be doing something tangibly different, whereas there's probably workarounds that are technically different but legally murky just because the output sounds the same (or even better) than "standard" mp3.


I have no clue what 'or even better than "standard" mp3' is supposed to mean. It's possible to design a codec that is free of MP3 patents and outperforms it. Vorbis and Opus do this.

If you want to have something that is compatible with MP3, i.e. will be decodable with an MP3 decoder, or decodes what an MP3 encoder made, this patent is a problem because it covers an essential operation in the filterbank. There are no "technically different" workarounds. You can choose not to run it, which has severe quality repercussions for an encoder, and which makes it impossible for your decoder to be truly compliant.
Go to the top of the page
+Quote Post
bawjaws
post Mar 21 2012, 12:18
Post #18





Group: Members
Posts: 173
Joined: 10-December 02
Member No.: 4043



QUOTE (Garf @ Mar 21 2012, 03:49) *
I have no clue what 'or even better than "standard" mp3' is supposed to mean. It's possible to design a codec that is free of MP3 patents and outperforms it. Vorbis and Opus do this.


What I meant was that in the end patents seem to eventually come down to convincing a jury of ordinary people in Texas. The mp3 encoder isn't standardized, just the decoder, but they do have encoder patents. So it's entirely possible to not do what is described in some of these patents and end up with a more efficient encoder.

To a layman, saying "we've managed to work around this fancy codec patent but as a result we lost all frequencies above 16kHz or added an occasional low hum" seems more "believable" than saying "these codec patents that people charge millions for aren't really that essential, look we've built an encoder even better than what is described in the patents without even using the techniques they describe" if you're in court accused by a big company of misusing their patents. So it was a comment about the possibility of avoiding actual, practical legal risk by doing something that makes no sense at all from either a technical perspective or a strictly theoretical legal perspective.
Go to the top of the page
+Quote Post
Garf
post Mar 21 2012, 13:24
Post #19


Server Admin


Group: Admin
Posts: 4884
Joined: 24-September 01
Member No.: 13



QUOTE (bawjaws @ Mar 21 2012, 12:18) *
So it was a comment about the possibility of avoiding actual, practical legal risk by doing something that makes no sense at all from either a technical perspective or a strictly theoretical legal perspective.


I have no idea what you mean here, specifically the "that makes no sense at all" part. But yes, in general I agree with the idea that simply not doing the patented operations is a much simpler defense that trying to come up with a technological alternative that avoids them (for example by skirting with the precise limitations of the patent claims).

And yes, you have more freedom in the encoder because that is not a normative part of the specification. But quite a few of the (remaining) patents are specifically on methods to make the encoder work well. It would not be unreasonable to presume the patent holders made sure making an efficient encoder wasn't possible without a patent license.

QUOTE
seems more "believable" than saying "these codec patents that people charge millions for aren't really that essential


I think it would be quite believable and explainable to a layman jury that, after half the patents in the pool, including the most fundamental ones, have expired, the remainder can be worked around.

QUOTE
look we've built an encoder even better than what is described in the patents without even using the techniques they describe


For some these, like 5742735, this is easy. But for some like 5703999 it would be quite hard to make it *better*.
Go to the top of the page
+Quote Post
bawjaws
post Mar 21 2012, 13:59
Post #20





Group: Members
Posts: 173
Joined: 10-December 02
Member No.: 4043



QUOTE (Garf @ Mar 21 2012, 03:49) *
QUOTE (bawjaws @ Mar 20 2012, 22:03) *
That's very cool. Is there a public source repository or even just some mp3 samples of its output available?

Take the latest LAME source and edit newmdct.c where it says "Perform aliasing reduction butterfly". The code suggests that running in all-short-blocks mode also avoids the patent.


When you say "severe" what kind of problems are you meaning, because when I comment out the body of that function or pass --allshort I don't hear any obvious difference in the output when I use lame with otherwise default settings on the soundtrack from the Sintel trailer provided in flac by Xiph. In fact from a very quick and unscientific test I can't tell the original WAV apart from any of them. The --allshort one is noticeably larger when I pass -V9 but I was expecting a more fundamental problem, one that couldn't be overcome by turning up the bitrate.

Have I messed up somehow, are my ears even worse than I previously thought, or do the differences only show up in certain circumstances?

This post has been edited by bawjaws: Mar 21 2012, 14:44
Go to the top of the page
+Quote Post
Garf
post Mar 21 2012, 20:29
Post #21


Server Admin


Group: Admin
Posts: 4884
Joined: 24-September 01
Member No.: 13



QUOTE (bawjaws @ Mar 21 2012, 13:59) *
when I comment out the body of that function


Body of that function? It's just those 9 lines below the comment.

QUOTE
or pass --allshort


Not running the anti-aliasing butterflies or not using long blocks are two different things.

QUOTE
I don't hear any obvious difference in the output when I use lame with otherwise default settings on the soundtrack from the Sintel trailer provided in flac by Xiph. In fact from a very quick and unscientific test I can't tell the original WAV apart from any of them.


It should be pretty obvious in music with tonal stuff or vocals, for example. It sounds a bit like weird extra harmonics or echoes.

QUOTE
The --allshort one is noticeably larger when I pass -V9 but I was expecting a more fundamental problem, one that couldn't be overcome by turning up the bitrate.


This is the expected result - long blocks are more efficient when encoding most types of music. Using only short blocks will give you a bit less quality on very tonal music and in general a higher bitrate for everything.
Go to the top of the page
+Quote Post
bawjaws
post Mar 23 2012, 21:22
Post #22





Group: Members
Posts: 173
Joined: 10-December 02
Member No.: 4043



Yeah, sorry, I meant comment out that If block, not comment out that function.

And I realize that --allshort is an even more blunt instrument, but either way I didn't notice much difference on a quick test which was a much more positive result than I was expecting.

Most of the other simple (possibly less than ideal) workarounds can be achieved with comand line flags to lame, yes?

5559834 --allshort (valid workaround but probably get better quality by changing code to skip the patent and let lame choose when to use short blocks)
5579430 ???
5627938 --noath
5703999, 5736943 & 5812672 mean -m can be simple, force, dual-mono or mono (simple is the default anyway at certain, I assume higher, bitrates) but not joint (without messing with the code that implements joint at least)
6185539 --resample 44|32|22 as appropriate at lower bitrates but default of "automatic" should generally be okay except at very low bitrates
6009399 ??
Go to the top of the page
+Quote Post
Prebsi
post Mar 28 2012, 17:35
Post #23





Group: Members
Posts: 2
Joined: 28-March 12
Member No.: 98152



Avoiding 5559834 by commenting out the butterfly code is not just "odd" or "strange". The aliasing is really, really bad.

I've compressed a series of sweeps using a plain encoder and one that was hacked. This is the spectral representation of the two files.



No points for guessing which one is the hacked! Most of the time there are two tones instead of just one.

The amplitude is also all over the place compared to the original and I had to attenuate the file by 1.5 dB in order not to distort it too much on decode.

This post has been edited by Prebsi: Mar 28 2012, 17:49
Go to the top of the page
+Quote Post
bawjaws
post Mar 30 2012, 17:00
Post #24





Group: Members
Posts: 173
Joined: 10-December 02
Member No.: 4043



QUOTE (Prebsi @ Mar 28 2012, 09:35) *
Avoiding 5559834 by commenting out the butterfly code is not just "odd" or "strange". The aliasing is really, really bad.


I'm trying to get a handle on some objective measure of "really, really bad". I assume those are at the same bitrate. How much would you have to increase the bitrate on the hacked version for it to match (visually and/or audibly) the patented version? Is it even possible? How does that bitrate increase generalize to other types of audio such as speech or popular music?

Go to the top of the page
+Quote Post
C.R.Helmrich
post Mar 31 2012, 12:11
Post #25





Group: Developer
Posts: 686
Joined: 6-December 08
From: Erlangen Germany
Member No.: 64012



QUOTE (bawjaws @ Mar 30 2012, 18:00) *
I'm trying to get a handle on some objective measure of "really, really bad". I assume those are at the same bitrate. How much would you have to increase the bitrate on the hacked version for it to match (visually and/or audibly) the patented version? Is it even possible? How does that bitrate increase generalize to other types of audio such as speech or popular music?

If I understood the inventor of that butterfly operation correctly (he's a colleague of mine), that operation is essential in order for mp3 to "not suck on tonal music" even at 320 kbps. The reason for the bad aliasing is that the MDCTs are computed on the sub-band values of the underlying pseudo-QMF bank of MPEG 1 Layers 1 and 2 (mp3 is Layer 3). Remember, the QMF bank does not perform any function in mp3 (other than to introduce the aliasing dry.gif).

Which is why the QMF bank was kicked out in AAC low-complexity (making the above butterfly operation unnecessary). Which is one of the reasons I - as a developer - prefer AAC over mp3 whenever I can.

Thanks, Prebsi, for the screenshot! I had never actually seen how bad the aliasing is.

Chris

This post has been edited by C.R.Helmrich: Mar 31 2012, 12:18


--------------------
If I don't reply to your reply, it means I agree with you.
Go to the top of the page
+Quote Post

2 Pages V   1 2 >
Reply to this topicStart new topic
1 User(s) are reading this topic (1 Guests and 0 Anonymous Users)
0 Members:

 



RSS Lo-Fi Version Time is now: 23rd August 2014 - 07:12