AnimeSuki Forums

Register Forum Rules FAQ Members List Social Groups Search Today's Posts Mark Forums Read

Go Back   AnimeSuki Forum > Anime Related Topics > Fansub Groups

Notices

Reply
 
Thread Tools
Old 2011-08-22, 13:28   Link #981
tyranuus
Team Spice and Wolf UK
 
 
Join Date: Feb 2010
Location: England
Age: 26
Hi guys,
Sorry to derail slightly from the current argument on 10bit encodes, but any comments appreciated:


Atm, I'm in the process of converting my BDs down to H264 in MKV to store on my different bits and pieces.
I'm typically ripping a raw copy of the videos with MakeMKV, re-encoding the video seperately, and then either remuxing in the original audio, or reencoding that if it saves a decent amount of space (ie THD to FLAC if it affords a decent space saving although seems more noticeable on DTS-MA), with the aim of producing a 'close to lossless' copy, rather than keeping the original raw file as...well it's pretty inefficient, and I can't really justify a 23GB raw rip, when a 5-7GB file may as well do the trick almost identically.

Now, I'm not much of an encoder and the reams of configureable options goes a little over my head at times, so I'm using Ripbot, or occasionally Handbrake if Ripbot doesnt do the job properly, and trying to adopt a basic 'one shoe size fits all policy' for the encodes so as to save me having to produce multiple encodes each time and choosing the one I like the best.

Looking through the file descriptions of a few groups I've never had any real issues with the PQ from, I've adjusted the default CRF down to 16.5, which mirrors the worst case scenario with these groups (which typically seems to be somewhere between 16.5 and 18 dependant on source, although one of them estimates the rough CRF and actually does 2 pass) and also fits inside the "CRF16-18 for virtually lossless" suggestion/rule I've seen in multiple different places.

Beyond this I'm typically using Ripbot's HD Progressive profile, at CF16.5.

On the last encode I did, throwing it into MediaInfo tells me it's used these x264 encode settings:
Quote:
cabac=1 / ref=3 / deblock=1:0:0 / analyse=0x3:0x133 / me=umh / subme=7 / psy=1 / psy_rd=1.00:0.00 / mixed_ref=1 / me_range=16 / chroma_me=1 / trellis=1 / 8x8dct=1 / cqm=0 / deadzone=21,11 / fast_pskip=1 / chroma_qp_offset=-2 / threads=12 / sliced_threads=0 / nr=0 / decimate=1 / interlaced=0 / constrained_intra=0 / bframes=3 / b_pyramid=0 / b_adapt=1 / b_bias=0 / direct=1 / weightb=1 / open_gop=0 / weightp=2 / keyint=240 / keyint_min=24 / scenecut=40 / intra_refresh=0 / rc_lookahead=40 / rc=crf / mbtree=1 / crf=16.5 / qcomp=0.60 / qpmin=0 / qpmax=69 / qpstep=4 / vbv_maxrate=25000 / vbv_bufsize=25000 / crf_max=0.0 / nal_hrd=vbr / ip_ratio=1.40 / aq=1:1.00
Can anyone see anything instantly retarded with the settings it's chosen, or does this seem to be relatively sound.
If anyone does have any criticism, as best as you can, could you possibly put a short explanation of *why*, as I'd like to learn why it's a mistake

Thanks!



*********
On the subject of 10bit, it seems a bit of a double edged sword, I can clearly see the benefit it brings, but the loss of ability to playback the files in anything except software decoding mode (on current hardware) is a real shame.
They're not as flexible, but with the power/heat/space savings that can be gained with hardware decoding, you can see why a lot of people are happier to stick with 8bit right now, especially as the whole hi10 scene has only recently been incorporated into the likes of CCCP.
__________________
Total Anime watched= Enough. What can I say? I'm a convert...
***
PRAY FOR SPICE AND WOLF III and faster Yenpress novel releases!
Reading: Rosario and Vampire II, Sankarea
tyranuus is offline   Reply With Quote
Old 2011-08-22, 19:45   Link #982
TheFluff
Excessively jovial fellow
 
 
Join Date: Dec 2005
Location: ISDB-T
Age: 27
Quote:
Originally Posted by tyranuus View Post
Can anyone see anything instantly retarded with the settings it's chosen, or does this seem to be relatively sound.
If anyone does have any criticism, as best as you can, could you possibly put a short explanation of *why*, as I'd like to learn why it's a mistake
if you're only encoding for your own personal use and aren't going to nerd out about encoding you don't really need to know anything about the details of each x264 switch. just pick a slower preset if the settings chosen don't compress well enough for you. even experienced encoders usually use the presets, and for good reasons.
__________________
| ffmpegsource
17:43:13 <~deculture> Also, TheFluff, you are so fucking slowpoke.jpg that people think we dropped the DVD's.
17:43:16 <~deculture> nice job, fag!

01:04:41 < Plorkyeran> it was annoying to typeset so it should be annoying to read
TheFluff is offline   Reply With Quote
Old 2011-08-23, 11:10   Link #983
tyranuus
Team Spice and Wolf UK
 
 
Join Date: Feb 2010
Location: England
Age: 26
Hahah, I may get nerdy/OCD at points, but usually not about x264 encoding.

I'm presuming you can't see any obvious 'wtf?!' problem's with Ripbot's H264 HD preset then, thanks a lot for the feedback
__________________
Total Anime watched= Enough. What can I say? I'm a convert...
***
PRAY FOR SPICE AND WOLF III and faster Yenpress novel releases!
Reading: Rosario and Vampire II, Sankarea
tyranuus is offline   Reply With Quote
Old 2011-08-23, 11:19   Link #984
TheFluff
Excessively jovial fellow
 
 
Join Date: Dec 2005
Location: ISDB-T
Age: 27
Quote:
Originally Posted by tyranuus View Post
I'm presuming you can't see any obvious 'wtf?!' problem's with Ripbot's H264 HD preset then, thanks a lot for the feedback
It doesn't look like a very slow preset. x264 has its own builtin presets; I recommend using those. I dunno where ripbot is getting its settings.
__________________
| ffmpegsource
17:43:13 <~deculture> Also, TheFluff, you are so fucking slowpoke.jpg that people think we dropped the DVD's.
17:43:16 <~deculture> nice job, fag!

01:04:41 < Plorkyeran> it was annoying to typeset so it should be annoying to read
TheFluff is offline   Reply With Quote
Old 2011-08-23, 11:30   Link #985
tyranuus
Team Spice and Wolf UK
 
 
Join Date: Feb 2010
Location: England
Age: 26
I'll be honest and say I've not got a clue what ripbot based the preset profiles on originally!

Looking into what it's profile entails, Ripbot says it's using these settings for the profile (obviously with your chosen CRF value)
Quote:
--level 4.0 --aud --nal-hrd vbr --vbv-bufsize 25000 --vbv-maxrate 25000 --filter 0,0 --ref 3 --bframes 3 --b-adapt 1 --b-pyramid none --subme 7 --aq-mode 1 --trellis 1 --partitions all --me umh
Not sure if that looks any closer to a known profile, or like a reasonable one at that, mind you!


Edit: Looking up the x264 various wikis, I'm presuming based on the Wiki, for my purposes of archiving (although not 1:1) without 100% focus on filesize, I'd be best to look at the "medium, slow, slower, veryslow, placebo" set of presets, perhaps with the --animation tag applied?

Command line something along the lines of "\x264_x64.exe --preset slow --tune animation --crf 16.5 -o <output file.h264/mkv> <input file>"
Perhaps with a --level 4.1 flag as well?

Doing this with a 256MB test file, once it'd been remuxed on the other side ended up with an output file of circa 88MB which is a pretty decent reduction, by contrast Ripbot's output was larger at about 113MB, with a higher bitrate. Now I'm not entirely sure if thats waste or going to any use!



Cheers for the assistance, Fluff, I figured it'd be best to ask about this sort of stuff, than sit there and either do something extremely stupid or realise after spending ages re-encoding a load of bits that the way it was done didn't quite cut the mustard, I've not got a bad system but this still takes a while hehe
__________________
Total Anime watched= Enough. What can I say? I'm a convert...
***
PRAY FOR SPICE AND WOLF III and faster Yenpress novel releases!
Reading: Rosario and Vampire II, Sankarea

Last edited by tyranuus; 2011-08-23 at 15:00.
tyranuus is offline   Reply With Quote
Old 2011-08-23, 15:03   Link #986
TheFluff
Excessively jovial fellow
 
 
Join Date: Dec 2005
Location: ISDB-T
Age: 27
Quote:
Originally Posted by tyranuus View Post
words
Ripbot's line has a number of weirdnesses in it and you're a lot better off with --preset slow --tune animation. If you want a smaller file, use a slower preset (or a higher CRF value). The --level flag is pure metadata and is only relevant if you use a hardware accelerated decoder that respects it. If you do not set it, x264 will set it for you automatically.
__________________
| ffmpegsource
17:43:13 <~deculture> Also, TheFluff, you are so fucking slowpoke.jpg that people think we dropped the DVD's.
17:43:16 <~deculture> nice job, fag!

01:04:41 < Plorkyeran> it was annoying to typeset so it should be annoying to read
TheFluff is offline   Reply With Quote
Old 2011-08-23, 15:21   Link #987
tyranuus
Team Spice and Wolf UK
 
 
Join Date: Feb 2010
Location: England
Age: 26
Not sure why but 'words' as the quote made me laugh, guess I'm too used too seeing 'snip', 'blah blah blah', 'stuff which need not be repeated'...anyhoo heh

In your experience I take it you'd say then that the extra bitrate average using that Ripbot profile is being wasted then? File size isn't a real issue for me, I'm more interested in getting decent output, so I don't mind higher bitrate if it's actually getting results, but if its being wasted...

I'll probably leave the level tags in, for the simple reason that, like you imply, it might give slightly better compatibility with hardware devices and x264 is also re-encoding at a higher FPS when set to 4.1 than 5/5.1, presumably because it's using fewer ref frames and are also seemingly slightly lesser compression.

I'd also thought that the different presets ie slow, slower etc were do with output quality rather than compression so again thanks for that heads up.

Again thanks a lot for the advice, if you use paypal PM me and I'd be happy to lob you over a little for a few brews on Thursday (payday) for the help
__________________
Total Anime watched= Enough. What can I say? I'm a convert...
***
PRAY FOR SPICE AND WOLF III and faster Yenpress novel releases!
Reading: Rosario and Vampire II, Sankarea
tyranuus is offline   Reply With Quote
Old 2011-08-23, 16:58   Link #988
gorgonite
C
 
Join Date: Oct 2010
You may seriously want to look at:

http://forum.doom9.org/showthread.ph...00#post1020500
http://akuvian.org/src/x264/ratecontrol.txt

On the other hand, I would suuggest using --b-adapt 2, because it"s a better algorithm that allows to use bframes more efficiently. And I might add: don't use VBV unless you really need it, it's disable by default for a reason.
Finally, you may consider using x264 directly and not relying on any GUI, you can write a simple *.bat file to make profiles, you just need to change the output and input names.
gorgonite is offline   Reply With Quote
Old 2011-08-23, 17:05   Link #989
tyranuus
Team Spice and Wolf UK
 
 
Join Date: Feb 2010
Location: England
Age: 26
I've been testing with x264 directly this evening rather than through any GUI following Fluff's previous recommendations, playing around with the presets primarily, along with --tune animation, and --b-adapt2 seems to be included by default in the slow/slower preset, I'm also pretty much doing what you've suggested, although with shortcuts rather than .bat files, although thanks for the links, will take a look

Atm I'm more or less settled with --preset slower --tune animation --level 4.1 --crf 16.5, outputting to an MKV container rather than directly to a .264 file as it means I can open it directly with MPCHC just to check the output quickly before remuxing the files.
The 2 minute test file I've been using to play around with ends up at 84.9MB via x264 direct based on the above, once I've remuxed the sub and audio tracks back in from the source file, whereas the equivalent file remuxed with the output from ripbot was ending up as 113MB, so doing it this way definately seems more space efficient, although I'm not 100% sure whether it was a case of Ripbot's profile throwing bitrate at unoptimised settings or whether its tailored for a certain scenario, unfortunately over the last year or two I kept forgetting to register at Doom9 and it's got a hefty 5 day wait period before I can even consider asking Ripbot's author about his choices.

One idiosyncracy I've noticed is that mediainfo seems to pickup my raw output as (incorrectly) about 1.2fps. Once I've muxed the audio back in however this resolves, bit strange but at least it's not affecting the files, although I do need to try reencoding the original audio stream before muxing this back in, and ensuring that it still works fine with 2 fresh source files, rather than the original components bar the video.
__________________
Total Anime watched= Enough. What can I say? I'm a convert...
***
PRAY FOR SPICE AND WOLF III and faster Yenpress novel releases!
Reading: Rosario and Vampire II, Sankarea

Last edited by tyranuus; 2011-08-23 at 17:17.
tyranuus is offline   Reply With Quote
Old 2011-08-23, 18:00   Link #990
TheFluff
Excessively jovial fellow
 
 
Join Date: Dec 2005
Location: ISDB-T
Age: 27
Quote:
Originally Posted by tyranuus View Post
I'll probably leave the level tags in, for the simple reason that, like you imply, it might give slightly better compatibility with hardware devices and x264 is also re-encoding at a higher FPS when set to 4.1 than 5/5.1, presumably because it's using fewer ref frames and are also seemingly slightly lesser compression.
Well, yes, if you haven't specified the number of reference frames explicitly, the --level flag will override that setting if it's detected to be necessary, so that probably explains the speed difference (--tune animation doubles the number of reference frames given by the preset, IIRC, so you usually end up with a lot even with fast presets). However, if you want to be 100% hardware compliant you must also set the proper VBV settings, and that can't be done manually. On the other hand, level 4.1's VBV limits are quite generous and under most circumstances you're not likely to exceed them.

Quote:
Originally Posted by tyranuus View Post
Again thanks a lot for the advice, if you use paypal PM me and I'd be happy to lob you over a little for a few brews on Thursday (payday) for the help
My advice is free and a way for me to make up for the bad karma I get from my usual modus operandi, which mostly consists of flaming people and telling them they're retarded (in many more words). Thanks for the offer, though.

Quote:
Originally Posted by tyranuus View Post
One idiosyncracy I've noticed is that mediainfo seems to pickup my raw output as (incorrectly) about 1.2fps. Once I've muxed the audio back in however this resolves, bit strange but at least it's not affecting the files, although I do need to try reencoding the original audio stream before muxing this back in, and ensuring that it still works fine with 2 fresh source files, rather than the original components bar the video.
That's a bug in MediaInfo, I'm pretty sure. Update it and see if it goes away.

Also, increasing the number of refs and b-frames can have drastic effects on compression efficiency of animated material, so that probably explains most of the size difference.
__________________
| ffmpegsource
17:43:13 <~deculture> Also, TheFluff, you are so fucking slowpoke.jpg that people think we dropped the DVD's.
17:43:16 <~deculture> nice job, fag!

01:04:41 < Plorkyeran> it was annoying to typeset so it should be annoying to read
TheFluff is offline   Reply With Quote
Old 2011-08-23, 23:44   Link #991
cyberbeing
Senior Member
 
 
Join Date: May 2006
Location: California
Unless you actually have something VFR, you should just specify --fps 24000/1001 (or whatever the framerate is) --force-cfr for compatibility if using x264 mkv output. By default x264 ffms vfr + mkv output doesn't write a default duration to the mkv and will break various software which stupidly assumes the splitter videoinfoheader will always contain the initial framerate. Not having a default duration for VFR is complaint with the MKV spec, but it's too bad there isn't a switch to force ffms out of VFR mode and just auto-detect a CFR.


Edit: I forgot that x264 had a --force-cfr switch, so you can used that instead of specifying a --fps if you want non-VFR output.

Quote:
Originally Posted by TheFluff View Post
That's a bug in MediaInfo, I'm pretty sure. Update it and see if it goes away.
I wouldn't be surprised if the bug in MediaInfo is caused by a VFR bug in the Haali Muxer. Normally with MediaInfo would show Variable w/ no fps for VFR mkvs without a default duration, but it's instead showing Constant w/ 1.199fps. Either way, the files should still be decoded correctly, since the timecodes are present (though rounded to the nearest integer).
__________________

Last edited by cyberbeing; 2011-08-25 at 08:26.
cyberbeing is offline   Reply With Quote
Old 2011-08-24, 01:57   Link #992
tyranuus
Team Spice and Wolf UK
 
 
Join Date: Feb 2010
Location: England
Age: 26
Thanks again, I did notice the 5.0/5.1 tests typically used 8/10 whereas the 4.1 only used 4, and Ripbot's only had 3, so I suspected this might have something to do with it.

One thing I've noticed is that dark scenes seem to show slightly more prevalent blocking under close inspection (possibly being anal but figure I might as well get it done right the first time); now I need to examine the video with a better screen as the one I'm writing this on doesn't really have a great colour depth and it could be an issue just being exacerbated by the screen dithering thats not really noticeable normally, as even the original BD rip shows it to a lesser degree, but I'm guessing that upping/reducing the CRF as needed, dependant on the point of view would be the best way of dealing with this, rather than reducing the preset speed?

Ie CRF 16.5-->15, rather than slower preset ---> veryslow

@cyberbeing - thanks for the tip on specifying the framerate, to prevent a bug in MKV output. Does it do the same if you just output to .264?
I'd only been using MKV output as it saved me a little time remuxing before checking a video.

If it doesn't I'll just alter my output by taking the .mkv specifier off the end, which I believe means it SHOULD save it as .264 (if you don't specify the file type - or am I wrong here too?)

Aka -o D:\WIP\Test instead of -o D:\WIP\Test.mkv or do I actually need to put .264 on the end?
__________________
Total Anime watched= Enough. What can I say? I'm a convert...
***
PRAY FOR SPICE AND WOLF III and faster Yenpress novel releases!
Reading: Rosario and Vampire II, Sankarea

Last edited by tyranuus; 2011-08-24 at 02:19.
tyranuus is offline   Reply With Quote
Old 2011-08-24, 08:43   Link #993
Desbreko
Senior Member
*Fansubber
 
 
Join Date: Apr 2009
Age: 26
Send a message via AIM to Desbreko
I wouldn't recommend using --tune animation for anime sources unless you override its aq-strength and psy-rd settings. It sets those two really low, which will cause much more banding and blocking in flat areas (such as low contrast areas in dark scenes) than the default values. I tend to use --aq-strength 1.0 (which is the default) and --psy-rd 0.8:0.1 (default is 1.0:0.0) for most anime, at least when encoding in 8-bit. Higher aq and psy will use more bitrate, but they'll probably be more efficient than just lowering crf.
Desbreko is offline   Reply With Quote
Old 2011-08-24, 11:42   Link #994
tyranuus
Team Spice and Wolf UK
 
 
Join Date: Feb 2010
Location: England
Age: 26
Cheers Desbreko, that might explain what I was noticing more obvious blocking in the dark scene, that's certainly worth bearing in mind if it'd resolve the issue as much as a lower CRF, but remain more efficient. Also, I guess if x264 is limiting the ref frames to 4 with level 4.1 there's not much benefit in the animation tag, if as Fluff says, it's main benefit is doubling the ref frames.

So in this case, do you believe it'd be better to use:
--preset slower --tune animation --level 4.1 --crf 16.5 --fps 24000/1001 --aq-strength 1.0 --psy-rd 0.8:0.1 -o <output.mkv> <input>

--preset slower--level 4.1 --crf 16.5 --fps 24000/1001 --aq-strength 1.0 --psy-rd 0.8:0.1 -o <output.mkv> <input>

OR

--preset slower --level 4.1 --crf 16.5 --fps 24000/1001 <output.mkv> <input>

Thanks all for the help!
__________________
Total Anime watched= Enough. What can I say? I'm a convert...
***
PRAY FOR SPICE AND WOLF III and faster Yenpress novel releases!
Reading: Rosario and Vampire II, Sankarea

Last edited by tyranuus; 2011-08-24 at 13:34.
tyranuus is offline   Reply With Quote
Old 2011-08-24, 18:49   Link #995
Shimapan
Try me! <3
 
 
Join Date: Apr 2011
Location: Germany
Age: 31
I've now worked my way through the descriptions for all the x264 settings and created a preset file for use with Avidemux
You can take a look at it here:
http://www.megaupload.com/?d=VPAI5UBT

Just load the preset in Avidemux and tell me what you think.
__________________
Shimapan is offline   Reply With Quote
Old 2011-08-24, 21:46   Link #996
Desbreko
Senior Member
*Fansubber
 
 
Join Date: Apr 2009
Age: 26
Send a message via AIM to Desbreko
Quote:
Originally Posted by tyranuus View Post
So in this case, do you believe it'd be better to use:
<trimmed>
I would go with the second one, and if you want to keep the other compression benefit from --tune animation (+2 b-frames), just set --b-frames 5 or above. Each extra b-frame will slow the encoding more, but for animation, even high numbers improve compression significantly.

You don't need to set aq-strength if you're not using --tune animation, though, since 1.0 is the default.
Desbreko is offline   Reply With Quote
Old 2011-08-25, 04:59   Link #997
tyranuus
Team Spice and Wolf UK
 
 
Join Date: Feb 2010
Location: England
Age: 26
Cheers Desbreko, so presuming I'm understanding correctly both:

--preset slower --tune animation --level 4.1 --crf 16.5 --fps 24000/1001 --aq-strength 1.0 --psy-rd 0.8:0.1

--preset slower--level 4.1 --crf 16.5 --fps 24000/1001 --bframes 5 --psy-rd 0.8:0.1

Should basically produce identical output; thanks a lot for the tips on the AQ/Psy-rd, as I'd probably have ended up just dropping the CRF to 15 or something, which like you say probably wouldn't have been the most efficient option.
I'll do some reencodes based on the above, and hopefully that'll clear up the blockiness in darkness; I don't mind the extra bitrate at all

@Pantsu, I'm no expert so couldn't give you much feedback, however I noticed you opted for QP when I took a peek at the XML (as I don't use Avidemux)
How much difference QP makes over CRF I don't know,but the reason I opted for CRF is I'm constantly seeing it recommended all over the place as achieving better file sizes at equivalent picture quality.
Example (3rd post):
http://forum.doom9.org/archive/index.php/t-107687.html

Typically, for small but decent picture quality encodes I've repeatedly seen the CRF 19-24 range recommended, for higher quality, more-or-less lossless I have seen 16-18 being the recommended region.

I based my choice of 16.5 on both the fact I wanted to be in the 'no obvious quality loss' space [16-18], and also by averaging out and comparing some releases from fansub groups who's releases I've enjoyed and not had any picture foibles with (which typically ranged between 16.5-19 with occasional flex on either side). As I've discovered myself though, some of the other tags you use/don't use during the encode can also make a difference to the picture quality
__________________
Total Anime watched= Enough. What can I say? I'm a convert...
***
PRAY FOR SPICE AND WOLF III and faster Yenpress novel releases!
Reading: Rosario and Vampire II, Sankarea

Last edited by tyranuus; 2011-08-25 at 05:53.
tyranuus is offline   Reply With Quote
Old 2011-08-25, 08:34   Link #998
cyberbeing
Senior Member
 
 
Join Date: May 2006
Location: California
I had a brainfart earlier. Since you are going for one-size-fits-all, it may be better to use --force-cfr instead of --fps, so you don't accidentally encode something at the wrong frame-rate by mistake.
__________________
cyberbeing is offline   Reply With Quote
Old 2011-08-25, 14:14   Link #999
PositronCannon
Senior Member
*Fansubber
 
 
Join Date: May 2010
Location: Spain
Age: 23
Quote:
Originally Posted by tyranuus View Post
@Pantsu, I'm no expert so couldn't give you much feedback, however I noticed you opted for QP when I took a peek at the XML (as I don't use Avidemux)
How much difference QP makes over CRF I don't know,but the reason I opted for CRF is I'm constantly seeing it recommended all over the place as achieving better file sizes at equivalent picture quality.
Just stick to CRF. Generally, the difference lies in that QP targets a certain "objective" quality for every frame, while CRF takes visual perception into account, allowing frames where a higher quality loss won't be as noticeable (such as high-motion scenes) to be compressed more. Treat it as a slightly variable QP. It maintains the same subjective quality throughout the video while lowering the filesize, meaning there's little reason to use QP unless you like watching action scenes frame by frame and want those frames to look crystal clear or something. :V
PositronCannon is offline   Reply With Quote
Old 2011-08-25, 18:45   Link #1000
tyranuus
Team Spice and Wolf UK
 
 
Join Date: Feb 2010
Location: England
Age: 26
Quote:
Originally Posted by cyberbeing View Post
I had a brainfart earlier. Since you are going for one-size-fits-all, it may be better to use --force-cfr instead of --fps, so you don't accidentally encode something at the wrong frame-rate by mistake.
No problem and thanks for the heads up, I think my material generally is 24.976 but ill switch over to that command line as it means I won't have to manually adjust.

Thanks again.
__________________
Total Anime watched= Enough. What can I say? I'm a convert...
***
PRAY FOR SPICE AND WOLF III and faster Yenpress novel releases!
Reading: Rosario and Vampire II, Sankarea
tyranuus is offline   Reply With Quote
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT -5. The time now is 05:11.


Powered by vBulletin® Version 3.8.7
Copyright ©2000 - 2014, vBulletin Solutions, Inc.
We use Silk.