IPB

Welcome Guest ( Log In | Register )

3 Pages V   1 2 3 >  
Reply to this topicStart new topic
CTDB question: Repair function
Skybrowser
post May 24 2010, 22:19
Post #1





Group: Members
Posts: 52
Joined: 7-January 10
Member No.: 76815



First off, i'd like to say that CTDB is probably the most useful and amazing tool i've seen since i started doing DAE a few months ago. Thankyou so much for creating something that can repair bad rips or essentially .. damaged CDs.

I've started using the CTDB repair function and i'm absolutely loving it. I'm struggling with a certain feature of it right now though.

Some of the albums I want to repair are showing up in the CTDB but when I attempt to verify them, it says for example " AR: offset 112, rip not accurate (0/116), CTDB: could not be verified ".

Now this seems to be happening pretty much only for albums where the accuraterip log shows matches for multiple offsets and the CTDB repair function won't activate and encode my files because it doesnt know which offset to use. I tried telling cuetools what offset to use in order to force the encode, but it wouldnt do it. I tried fixing the offset of the files just incase that was causing it, but that wouldnt do it either. Now I know the repair function can only repair a certain amount of errors, but for these albums i dont think the error count would be that high. I think the CTDB just gets stuck when it doesnt know which offset to use..... which is weird, because if you look at the bold text above, cuetools + AR is able to figure out the right offset. Is there a way of telling the CTDB to use the offset that AR is seeing and then repairing the damaged tracks? This situation doesnt happen in all cases with multiple offsets, but just mostly when there is a large number of offsets or the confidence for track matches are quite similar for each of the offsets
Again, this DB is awsome. If you have the time to populate it with your verified albums then please do so, because everyone benefits in the end.

This post has been edited by Skybrowser: May 24 2010, 22:27
Go to the top of the page
+Quote Post
sauvage78
post May 24 2010, 22:31
Post #2





Group: Members
Posts: 677
Joined: 4-May 08
Member No.: 53282



Plz post the complete cuetools log so that we can understand you with "your offset fixing thing" ... which is chineese to me right now wink.gif

As far as I understund what you meant: If the rip doesn't get accurate result for all tracks within the same offset it cannot be AR2 hence it cannot be repaired no matter if the tracks are all accurate separately on several different offsets (which happens sometimes). In this case it can be repaired but only if it is really damaged not if the fact that it is not AR2 is due to holes in the AR database.

Without any additionnal clue that there is a real scratch (a bad EAC log) you rip could be perfect & yet not in the AR database ...

I dunno if what I said matches your case but all I say is that you didn't provided enougth information to conclude anything.

This post has been edited by sauvage78: May 24 2010, 22:44


--------------------
CDImage+CUE
Secure [Low/C2/AR(2)]
Flac -4
Go to the top of the page
+Quote Post
greynol
post May 24 2010, 22:44
Post #3





Group: Super Moderator
Posts: 10338
Joined: 1-April 04
From: San Francisco
Member No.: 13167



AR2?


--------------------
Your eyes cannot hear.
Go to the top of the page
+Quote Post
sauvage78
post May 24 2010, 22:46
Post #4





Group: Members
Posts: 677
Joined: 4-May 08
Member No.: 53282



Short for Accurate with confidency confidence 2.

Myself:
QUOTE
If the rip doesn't get accurate result for all tracks within the same offset it cannot be AR2 hence it cannot be repaired no matter if the tracks are all accurate separately on several different offsets (which happens sometimes).


This whole sentence is not really worded correctly anyway ... I say it cannot be repaired & then I say it can ...

Skybrowser:
QUOTE
CTDB repair function won't activate and encode my files because it doesnt know which offset to use.

As I tried to explained with bad words, CTDB knows that it knows nothing, so it does nothing.

This post has been edited by sauvage78: May 24 2010, 22:52


--------------------
CDImage+CUE
Secure [Low/C2/AR(2)]
Flac -4
Go to the top of the page
+Quote Post
greynol
post May 24 2010, 22:50
Post #5





Group: Super Moderator
Posts: 10338
Joined: 1-April 04
From: San Francisco
Member No.: 13167



Some sort of shorthand you've made up, I suppose. AR2 has already been taken for the next generation of AccurateRip, so I think you might want to come up with something else.

Regardless, we already know that a confidence of one is all you need provided it wasn't your previous submission, barring consistent errors due to manufacturing defect, software bug or firmware bug; in which case a confidence of two is still no guarantee.

EDIT:
The reason I asked is that you gave me the impression that spoon has somehow adopted CTDB as part of AR. Knowing now that this is not the case, I think I should point out to the OP that AR and CTDB are two different databases, independent of one another. Just because you might get a hit against the AR database does not mean you'll be able to fix the title with CTDB. Perhaps this is already known to the OP; I'm not all that familiar with the new lingo since CTDB has not yet been able to help me with a bad rip and because I have very few titles that need to be fixed, I have very little experience with it.

This post has been edited by greynol: May 24 2010, 23:09


--------------------
Your eyes cannot hear.
Go to the top of the page
+Quote Post
sauvage78
post May 24 2010, 23:02
Post #6





Group: Members
Posts: 677
Joined: 4-May 08
Member No.: 53282



Greynol:
I know all this, but still I use AR2 for safety, because as far as I understund AR1 rip can vanish from the database due to the way it works ... I have noticed this several times ... AR1 seems to be pending rips ... starting at AR2 the rips never vanish from the database (well so far I haven't noticed any AR2+ vanishing from the database. Edit: Outside of purges indeed) ... also I use AR2 as a reference even more now as CTDB accept submission starting at AR2. If I ever find AR2 faulty be sure I'll complain to the boss !

So even if AR1 is enougth if you own the CD, in the end the fact that a rip can be AR1 in April & not in database in May makes you feel that AR1 is not enougth.

I am not sure but I think I already used this shorthand with Gregory & we did understund each other I think, maybe it would be harder with Spoon. But I thought the whole idea behind AR2 (the new database I mean here) was forgotten for now anyway.

Greynol:
QUOTE
independent of one another
Well CTDB is AR dependent.
There is not much to understand in CTDB. It's either the rip is in database or it's not. Once it is in database it's either it's fixable or not ...

This post has been edited by sauvage78: May 24 2010, 23:17


--------------------
CDImage+CUE
Secure [Low/C2/AR(2)]
Flac -4
Go to the top of the page
+Quote Post
greynol
post May 24 2010, 23:17
Post #7





Group: Super Moderator
Posts: 10338
Joined: 1-April 04
From: San Francisco
Member No.: 13167



A confidence of one that vanished is really no better than a confidence of one that did not vanish, or any better than a confidence of two provided it was not your previous submission.

QUOTE
If I ever find AR2 faulty be sure I'll complain to the boss !
You might want to say something other than AR2 or you might confuse him.

QUOTE
So even if AR1 is enougth if you own the CD, in the end the fact that a rip can be AR1 in April & not in database in May makes you feel that AR1 is not enougth.
Speak for yourself, it doesn't make me feel that way. wink.gif

QUOTE
CTDB is AR dependent.
How so exactly? Must there be a record in the AR database for something to be in the CT database?

This post has been edited by greynol: May 24 2010, 23:22


--------------------
Your eyes cannot hear.
Go to the top of the page
+Quote Post
sauvage78
post May 24 2010, 23:24
Post #8





Group: Members
Posts: 677
Joined: 4-May 08
Member No.: 53282



QUOTE
How so exactly?

Just like you said Greg uses AR2 to accept submission, so no AR no CTDB simply.
Without AR2 there would be no way to dismiss noise (scratched submission) from CTDB.

I think it would technically be possible to create an independent CTDB, by comparing submissions, but it would be hard for Gregory for no gain as AR already does that. To be short if Greg would have made CTDB independent he would have needed to reinvent the wheel ... the wheel being AR.

Edit:
You were faster:
QUOTE
Must there be a record in the AR database for something to be in the CT database?

Yes AR2 in AR database before being accepted in CTDB ... I learned something to Greynol ! unbelievable wink.gif

QUOTE
A confidence of one that vanished is really no better than a confidence of one that did not vanish, or any better than a confidence of two provided it was not your previous submission.

I am not sure that I get what you meant but a confidence of 2 no matter if one is your own "precious" submission is better than a confidence of 1 because a confidence of 1 is almost like no confidence at all for me ... as it can disapear. To trust AR1 you have to keep records of what you submitted to the database which is insane in the long time.

This post has been edited by sauvage78: May 24 2010, 23:31


--------------------
CDImage+CUE
Secure [Low/C2/AR(2)]
Flac -4
Go to the top of the page
+Quote Post
greynol
post May 24 2010, 23:27
Post #9





Group: Super Moderator
Posts: 10338
Joined: 1-April 04
From: San Francisco
Member No.: 13167



QUOTE (sauvage78 @ May 24 2010, 15:24) *
Just like you said Greg uses AR2 to accept submission, so no AR no CTDB simply.

I either didn't say this or have given you the wrong impression as this is not true. CUEripper will submit to the CT database without an AR entry.


--------------------
Your eyes cannot hear.
Go to the top of the page
+Quote Post
greynol
post May 24 2010, 23:28
Post #10





Group: Super Moderator
Posts: 10338
Joined: 1-April 04
From: San Francisco
Member No.: 13167



QUOTE (sauvage78 @ May 24 2010, 15:24) *
Yes AR2 in AR database before being accepted in CTDB

Actually, no, this is not right; the intention of my question was rhetorical. See my previous response.

QUOTE (sauvage78 @ May 24 2010, 15:24) *
I am not sure that I get what you meant but a confidence of 2 no matter if one is your own "precious" submission is better than a confidence of 1 because a confidence of 1 is almost like no confidence at all for me ... as it can disapear. To trust AR1 you have to keep records of what you submitted to the database which is insane in the long time.

It is just a snapshot at any particular moment. In the long run, a confidence of one that disappeared will eventually re-appear if it was right. If it was right it was no less right when it disappeared. If it wasn't your previous submission then it definitely was right.

If you suffered from a drive failure or had some other reason to re-rip your collection after a submission, then I understand. Otherwise if you know you haven't previously submitted a disc (which is a question that is probably very easy to answer for most people) then there is no reason to throw away a log with a confidence of one to later test it to make sure it got bigger. In my case it's simple: I don't believe I've ever submitted to AR. Furthermore, if I have I can pretty well guarantee that my submissions never made it to the database because I've been banned for a long time now.

So what if you've submitted more than once to the database with a different AR user ID? Can you still trust a confidence of two? This is a rhetorical question (the answer is no). It's also a legitimate concern as I know at least one person who has and I have to agree with you: keeping a record of what you've submitted and how many times is insanity.

This post has been edited by greynol: May 25 2010, 01:04


--------------------
Your eyes cannot hear.
Go to the top of the page
+Quote Post
sauvage78
post May 24 2010, 23:36
Post #11





Group: Members
Posts: 677
Joined: 4-May 08
Member No.: 53282



Yes you're right, but I think this is temporary (Edit: Should have been). CTDB only accept CUEripper because Spoon doesn't accept CUEripper results in AR database. Once CUEripper will be mature enougth to be accepted in AR database then AR2 should be the norm.

Maybe Greg will always accept CUEripper results because he trust his own works, but overall the truth is that accepting CUEripper is a sort of trick. An acceptable trick.

This post has been edited by sauvage78: May 24 2010, 23:44


--------------------
CDImage+CUE
Secure [Low/C2/AR(2)]
Flac -4
Go to the top of the page
+Quote Post
greynol
post May 24 2010, 23:40
Post #12





Group: Super Moderator
Posts: 10338
Joined: 1-April 04
From: San Francisco
Member No.: 13167



I think Gregory would take exception to the idea that it's a trick.

Perhaps you can provide a link to him saying it's just a trick and that he'll make the CT database dependent on the AR database once CUERipper is allowed to submit to the AR database?

This post has been edited by greynol: May 24 2010, 23:51


--------------------
Your eyes cannot hear.
Go to the top of the page
+Quote Post
sauvage78
post May 25 2010, 00:18
Post #13





Group: Members
Posts: 677
Joined: 4-May 08
Member No.: 53282



He never said that, it was just obvious to me.

In this post I argue that the CTDB confidence is an artificial number that shouldn't exist if CUERipper results were accepted in the AR database.

Greg didn't reacted to this so I assumed my assumption was right.

I may be completely wrong & Greg may disagree, it wouldn't be the first time that I would be wrong about AR & CTDB.

From a human point of view it is just logic that CTDB accepts CUERipper results, CTDB & CUERipper are time greedy for Greg & the possibility that accepting CUERipper in CTDB might help him to find bugs or even just help him improve CUERipper is the least that we can accept as a sort of "reward" for his job.

If we trust CTDB then we trust Greg's work so trusting him for CUERipper too is the least that we can do, to show him our trust.

This post has been edited by sauvage78: May 25 2010, 00:23


--------------------
CDImage+CUE
Secure [Low/C2/AR(2)]
Flac -4
Go to the top of the page
+Quote Post
greynol
post May 25 2010, 00:39
Post #14





Group: Super Moderator
Posts: 10338
Joined: 1-April 04
From: San Francisco
Member No.: 13167



So is the answer as simple as the OP's disc not being in the database, or is it likely something else? Again, I'm not really all that familiar with all the new logs and whatnot.


--------------------
Your eyes cannot hear.
Go to the top of the page
+Quote Post
sauvage78
post May 25 2010, 00:50
Post #15





Group: Members
Posts: 677
Joined: 4-May 08
Member No.: 53282



Yes, as far as I understund, it can be as simple as that wink.gif As long as he doesn't provide a full cuetools log, I dunno.

I think that he has a log where all tracks are accurate separately somewhere but not on the same offset, so he thinks he can fix it. (When I was an AR beginner I tried to fix manually a rip like that (by applying offset/splitting/joining) which is a strange & funny idea to think about now blink.gif Like what the hell was I thinking of !!! Indeed it didn't work & I created a monster) If that's it ... his rip is maybe perfect, but the pressing simply not in the database. Cuetools doesn't want to fix it, as there is no evidence that it is broken.

Maybe it is something else, I dunno.

This post has been edited by sauvage78: May 25 2010, 01:07


--------------------
CDImage+CUE
Secure [Low/C2/AR(2)]
Flac -4
Go to the top of the page
+Quote Post
Skybrowser
post May 25 2010, 02:08
Post #16





Group: Members
Posts: 52
Joined: 7-January 10
Member No.: 76815



Ok.... well following that massive discussion between you two wasnt easy, but I think i caught a few things here and there and i'll try to respond.

- So far i've repaired 7 CDs, and I have about 123 to go..... sooo you can see why I'm quite passionate about this.

- The situation I am talking about is when the rip is identified in both AR and CTDB with more than 2 confidence.

- Like Greynol said, your use of AR2 was a tad bit confusing. I am going to assume that every time you used it, you were referring to a rip with AR confidence >2

- Yes Greynol, CTDB submissions require AR confidence >=2

- I thought i saw one of you mention something about a bad log file or something. Could my original EAC log files be confusing CT somehow?

- I will give you an example. I hope it helps. This is an example of one where I didnt fix the offset. But even if i fix the offset, it just says 'cannot be verified' in cuetools for CTDB. As you can see there are 337 CTDB confidence, and around 560 AR confidence.

CODE
[CUETools log; Date: 24/05/2010 5:27:41 PM; Version: 2.0.9]
[CTDB TOCID: be8vy8P3FbyY5zsvkRW5op85K_o-] found.
[ CTDBID ] Status
[4135cf03] (337/337) No match
[AccurateRip ID: 0017deff-00cf9b72-890dd20b] found.
Track [ CRC ] Status
01 [8164b9a6] (000/562) No match
02 [8d6e86c8] (000/563) No match
03 [1ad0833b] (000/565) No match
04 [458425a6] (000/565) No match
05 [b2b0db89] (000/568) No match
06 [b87e1bef] (000/562) No match
07 [c4209825] (000/557) No match
08 [de139d6c] (000/566) No match
09 [ab4603ce] (000/563) No match
10 [49f419f5] (000/558) No match
11 [71e15541] (000/540) No match
Offsetted by 112:
01 [4e5b16c2] (039/562) Accurately ripped
02 [3cf51194] (039/563) Accurately ripped
03 [c9ba3e97] (039/565) No match but offset
04 [fc7c30b5] (040/565) Accurately ripped
05 [a548029a] (040/568) Accurately ripped
06 [e4ed989c] (038/562) No match but offset
07 [3f9d7f5d] (039/557) No match but offset
08 [c37a916d] (039/566) No match but offset
09 [ac5ad610] (038/563) Accurately ripped
10 [5ea5e171] (039/558) No match but offset
11 [cc46d7c1] (039/540) No match but offset

Track Peak [ CRC32 ] [W/O NULL] [ LOG ]
-- 97.7 [676A08B4] [F6C8BC1A]
01 97.7 [04B564BA] [6A33D5F9] CRC32
02 97.7 [3DC55F78] [0296C6D0] CRC32
03 97.7 [AA7422DC] [43358095] CRC32
04 97.7 [0251F8EF] [A91411AA] CRC32
05 97.7 [4FD3CD70] [24E1DABF] CRC32
06 97.7 [43E1D1C6] [E45B33D8] CRC32
07 97.1 [618BD826] [5C35B999] CRC32
08 97.7 [5A9E0514] [23BB1B34] CRC32
09 97.7 [645C41ED] [DF1D3E84] CRC32
10 97.7 [DABC5DF3] [90290BF6] CRC32
11 97.7 [C8636CF9] [8B7161C9] CRC32

Go to the top of the page
+Quote Post
sauvage78
post May 25 2010, 02:39
Post #17





Group: Members
Posts: 677
Joined: 4-May 08
Member No.: 53282



With your last cuetools log: this rip is not accurate with a very very high confidence so it is not surprising that CTDB cannot fix it ... there is two possibility:

1: Very likely: the rip is not accurate & is scratched beyond repair.
2: Very unlikely: you own a rare pressing that is not in AR & doesn't match CTDB too

The possibility N2 is still opened because of "Offsetted by 112:", so if you didn't fix the drive offset while ripping & the drive offset is +112, then possibility N2 is closed & your rip is damaged.

QUOTE
- I thought i saw one of you mention something about a bad log file or something. Could my original EAC log files be confusing CT somehow?

This is where your EAC log will maybe help you, the records of the drive offset will maybe close possibility N2. Other than that the EAC log is only usefull when the CD is enhanced & only if the log incluses the TOC.

Also:
QUOTE
337 CTDB confidence
be warned that as far as I understund this doesn't mean that 337 users submitted to CTDB, but only that the one that was submitted matches with AR at up to 337 accurate rips.

This post has been edited by sauvage78: May 25 2010, 02:48


--------------------
CDImage+CUE
Secure [Low/C2/AR(2)]
Flac -4
Go to the top of the page
+Quote Post
greynol
post May 25 2010, 02:46
Post #18





Group: Super Moderator
Posts: 10338
Joined: 1-April 04
From: San Francisco
Member No.: 13167



QUOTE (Skybrowser @ May 24 2010, 18:08) *
- Yes Greynol, CTDB submissions require AR confidence >=2

I knew this already, however CTDB submissions from CUERipper don't require any AR confidence, so it is possible for there to be CTDB entry that does not exist in AR (IOW, the two databases are independent). Either way, I'm glad to see this part of your problem has been addressed.

This post has been edited by greynol: May 25 2010, 02:46


--------------------
Your eyes cannot hear.
Go to the top of the page
+Quote Post
greynol
post May 25 2010, 02:50
Post #19





Group: Super Moderator
Posts: 10338
Joined: 1-April 04
From: San Francisco
Member No.: 13167



QUOTE (sauvage78 @ May 24 2010, 18:39) *
With your last cuetools log: this rip is not accurate with a very very high confidence
Sorry to nitpick again, but this is misleading. Confidence applies to something that is accurate, not to something that is not accurate.

QUOTE (sauvage78 @ May 24 2010, 18:39) *
2: Very unlikely: you own a rare pressing that is not in AR & doesn't match CTDB too
I don't see how you are able to assess that this is not likely, especially without a rip log. Where was the CD produced, how many were produced from that run, was the data edited between production runs
(click removal/eq/etc.), where and when was it purchased, how long ago was it released, how many copies were sold?

This post has been edited by greynol: May 25 2010, 02:57


--------------------
Your eyes cannot hear.
Go to the top of the page
+Quote Post
sauvage78
post May 25 2010, 02:53
Post #20





Group: Members
Posts: 677
Joined: 4-May 08
Member No.: 53282



I may be wrong but I think that CTDB still requires an accuraccy of 1 even for CUERipper, there is a AR column in the CTDB page & I don't recall having seen any AR0 ... for me it is logic as an AR1+a CD in CUERipper means that the submission in AR is not from the same guy ... so in fact AR1+CUERipper 1= AR2 ... that's how I understand it.


--------------------
CDImage+CUE
Secure [Low/C2/AR(2)]
Flac -4
Go to the top of the page
+Quote Post
Skybrowser
post May 25 2010, 03:00
Post #21





Group: Members
Posts: 52
Joined: 7-January 10
Member No.: 76815



- My drive offset in logfiles for ripping is 667.

- The reason it says 112 in CT is because its a CDR. Thats why I mentioned fixing the offset earlier, i tried fixing offsets and still had the problem. Now i know what you're thinking, 'the problem is probably that its a bad burn' BUT I have already used CTDB to repair rips from burns that dont look damaged.... bad burns are repairable too and thus are not the problem.

- So how do i know the difference between an album that is unrepairable by CTDB and any other error i'm having? Do you think I should suggest to the developer that he uses different messages? One that notifies you that your album has too many errors to repair and one that says your album is not being recognized by the database or something?

This post has been edited by Skybrowser: May 25 2010, 03:02
Go to the top of the page
+Quote Post
sauvage78
post May 25 2010, 03:01
Post #22





Group: Members
Posts: 677
Joined: 4-May 08
Member No.: 53282



Well what is likely or not is only a question of probability, it's like poker if you have 2 aces in the hand you have a big probability to win ... but you can still lose.

Reading non accurate Cuetools log is like that ... with the information that he provided there is actually more chance that his rip is not accurate. If his EAC log confirm the drive offset then it's like drawing an additionnal ace wink.gif If you get what I mean wink.gif

It's a question of habbit. You have to much non-scratched CD wink.gif

This post has been edited by sauvage78: May 25 2010, 03:02


--------------------
CDImage+CUE
Secure [Low/C2/AR(2)]
Flac -4
Go to the top of the page
+Quote Post
sauvage78
post May 25 2010, 03:03
Post #23





Group: Members
Posts: 677
Joined: 4-May 08
Member No.: 53282



Ok I completely forgot that it was a CDR, well for me the rip is not accurate & beyond repair or you have a different pressing I can't tell. The fact that it is a CDR blurs the verdict, still even without certainty this rip is very suspicious IMHO.

QUOTE
- So how do i know the difference between an album that is unrepairable by CTDB and any other error i'm having? Do you think I should suggest to the developer that he uses different messages? One that notifies you that your album has too many errors to repair and one that says your album is not being recognized by the database or something?

I think CTDB has no way to know if it doesn't match because of pressing difference or because of scratches, hence the message doesn't make any difference. So my guess is that asking Greg for this will not help. I suspect that if it was possible Greg would have been clever enougth to make this difference. ... well I hope wink.gif

This post has been edited by sauvage78: May 25 2010, 03:17


--------------------
CDImage+CUE
Secure [Low/C2/AR(2)]
Flac -4
Go to the top of the page
+Quote Post
Skybrowser
post May 25 2010, 03:41
Post #24





Group: Members
Posts: 52
Joined: 7-January 10
Member No.: 76815



I already have a few encountering this situation. Like is the CTDB only really powerful enough to repair about 1 track? should i base it on how many in-accurate tracks I have on a specific CDR?
Go to the top of the page
+Quote Post
sauvage78
post May 25 2010, 03:48
Post #25





Group: Members
Posts: 677
Joined: 4-May 08
Member No.: 53282



The ability of CTDB to repair damaged rips is random, the only thing you can do is accepting it. Based on my small experience, so far I would say that if the rip is in CTDB you have 50% (maybe a little less) chance to be able to fix it (note that this estimation is likely very random too). It is (much) better than nothing, just be happy that CTDB exists.

I have already fixed rip with more than hundreds of difference (But it only happened once so far) so it's pure luck. You cannot draw any conclusion from the accuracy of tracks in cuetools log & extrapolate it to the ability of CTDB to fix it.

The ability of CTDB to repair damaged rips seems to rely much more on how many data Greg decide to store in the database. But the more data he stores the bigger & harder to manage the database becomes.

This post has been edited by sauvage78: May 25 2010, 04:18


--------------------
CDImage+CUE
Secure [Low/C2/AR(2)]
Flac -4
Go to the top of the page
+Quote Post

3 Pages V   1 2 3 >
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: 20th December 2014 - 04:09