AnimeSuki Forums

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

Go Back   AnimeSuki Forum > Anime Related Topics > General Anime > Fansub Groups

Notices

Reply
 
Thread Tools
Old 2007-10-21, 04:37   Link #1
Mentar
Banned
 
 
Join Date: Nov 2003
Location: Hamburg
Age: 54
Workflow HOWTO for encoding dual-version releases

Recently I've been asked once again to give some hints how to deal with dual-release encoding issues. Since I've got some spare time, I've compiled this little HOWTO describing an optimized workflow for encoding dual releases, in the hope that one or two encoders might find it useful. Constructive feedback and improvement suggestions are always welcome.

Synopsis

This little text describes the workflow I'm currently using to encode dual version anime releases - one high resolution softsubbed MKV release and one standard resolution hardsubbed AVI release, from a 120fps raw source. For the sake of simplicity, I'll skip over variable framerame encoding, which gets VERY complicated in the dual-release context, and assume normal constant framerate sources - if there is serious interest in this, I might write another article later.

It is by no means the "only" way to do it, and even less the "best" way, but it's a workflow which has been developed and refined over the years and has proven its worth. One can argue that there are newer tools available for the tasks, but I prefer to stick with the "tried-and-true" versions until some new feature surfaces which really justifies an upgrade.


Requirements

Except for sufficient knowledge in encoding theory and handling the basic tools (virtualdub, x264/MeGUI etc.) you need at least basic knowledge in avisynth scripting, and you need sufficient free diskspace on your encoding machine. Minimum is 15GB for normal-resolution sources and 30 GB for high-resolution sources. The tools I'm using are:

Virtualdub
Virtualdubmod
Avisynth 2.5.6a (you can try 2.5.7 if you want, I prefer the older version)
x264 with MeGUI
MKVtoolnix
Aegisub
Audio tools (Besweet, NeroAACenc, etc)


Workflow


1) Raw selection

Usually, most groups will have access to japanese P2P networks like Winny or Share and thus have access to various types of raws. In general, the translator can start with the first raw available, but nothing affects the quality of a release more than the raw selection. The best encoder can't turn a dogpile into caviar, so pick your release raw with care. If you happen to work in a group which leaves this decision to the encoder, just the better.

2) Loading the Video

It's very common nowadays to get raws encoded in 120fps, which is AVI's kludge to incorporate pseudo-VFR (23.976 and 29.97fps sequences) in one file. Since this is impossible to play back properly after manipulation, we need to decimate this video down to the target constant frame rate (usually 23.976, sometimes 29.97) due to the AVI container limitations.

There are many different ways to do this decimation, and the process is non-deterministic: The different approaches lead to frames being off by 1(!). This is very critical for scenetiming and especially for typesetting, so you should prepare a workraw in any case. The idea is to make sure that timers and typesetters always use this easily-handleable workraw and NOT on the clunky original raw.

This is an example how I decimate the video for Hayate via avisynth script:

Quote:
directshowsource(fps=29.97,convertfps=true,"Hayate 30.avi").converttoyv12()
This decimates the framerate to 29.97fps, and it also guarantees YV12 colorspace for later. I'm usually careful and crop 2-4 pixels away from each side of the video, and then resize back up to the target resolution, but that's up to everyone to decide.

However, if you plan to release a h264 version, make sure you resize to mod16 - that's usually 704x400, 640x480, 1024x576, 1280x720. If you're strapped for diskspace, do the Audio step 3) first now and then disable the audio in Virtualdub. Otherwise just proceed, select Xvid single-pass with quant 3, and disable b-frames(!)

The point is that the workraw (TSraw) should have no b-frames or anything which would make the job more error-prone for the timer and typesetter. Quant3 makes for a decent, albeit not amazing video - it should be close enough to the final result to make sure that the typesetter can work with fine details too. On the other hand it shouldn't be TOO large too, since it needs to be downloaded. If your timer is on a terrible line in Portugal, you can also create a "Crapraw" with quant 10 - easily downloaded, and it still has the keyframes he'll need for the Aegisub timing postprocessing later.

Always work with the FULL resolution. Even if the avi will be smaller eventually, the typesetter should work on the full resolution instead. The AVI will only be downscaled eventually. This way, you only work on ONE version, not on multiple ones.

Once the TSraw is encoded, do the Audio step 3) and mux the created MP3 audio into the TSraw for the final version. Give it an easily understandable name (e.g. Hayate-30-TSraw-xvid-nobframes.avi), upload it to your project FTP server and notify the others that it's up.

3) Audio extraction and preparation

There are several possibilities here. If your release contains audio in a form which you want to reuse "directly" without re-encoding it, you can just extract it via Virtualdub (using the _original_ raw, not the directshow line quoted up above, because it will force a conversion to WAV). In most cases however, the bitrate will be too high (192 or up) to fit your target releases, or you will want to reencode in Vorbis and AAC in lower bitrates to save space. Here, I tend to use VirtualDub to create a WAV file called "Audio.wav" of ~270 megs. Then, use your favorite audio tools to convert it to an MP3 for the AVIs and either a vorbis or AAC version for your MKV. If you want to keep the original audio of a MKV or MP4 source for your own MKV release, you don't need to do anything - just load the original raw in mmg later and only tick the audio to be muxed in.

4) Filtering of the original raw

Filtering of raws, especially high-resolution raws, can be very very time-consuming (depending on the encoder's computer horsepower available, we're talking several hours for a pass). Therefore, it's very efficient make only a single filterpass, and to store the result in a lossless AVI.

So, we create another avisynth script, with EXACTLY THE SAME (!) decimation and cropping/resizing lines, but this time with the desired filtering too. I prefer Lagarith as lossless codec, but ffv1 is fine too, or huffyuv (though the latter is fairly inefficient and takes more diskspace).

Save the file to an equivalent of "Hayate-30-prefiltered.avi" and go to bed. This will usually take a while. Time for the others (translator, editor, timer, typesetter etc) to do their job. You sleep and pick up their work results in the morning.

5) Adding AFX signs

If you don't use AFX, just skip this point. If you do, then add them to the _prefiltered_ lossless AVI. The result should be an avisynth file which loads the prefiltered AVI and overlays all AFX signs. Make sure you check each sign visually, for bleeds or other glitches.

6) Adding ASS signs

Time to open up Aegisub and to either load the Step 5)-generated Avisynth script or the prefiltered AVI directly. Then, load the ASS signs script from your typesetter (always insist on a seperate file, NEVER add signs to the main dialogue script!)

Go through all entries and check all ASS signs, to make sure that they're clean. It's also a good idea to make a "Fonts collector" check in Aegisub to make sure that you have all fonts installed.

The result should be a checked and clean ASS script.

7) Shifting/Checking the Karaoke

If you're lucky that others shift the OP/ED/Insert Karaokes for you, only make quick xvid one-pass ranged OP/ED test encodes in Virtualdub, with the Audio.wav extracted in step 3) selected as "WAV Audio". If all is good, proceed. If not, fix the timing or poke whoever does this in your group.

8) Putting it all together

Now it's time to create one more "final" lossless video. It should contain everything but the dialogue script. Since you have checked all signs and karaokes already, the only glitches which should appear from now on are in the dialogue, so it's smart to finalize anything else.

Load the AFX-adding avisynth file in vdub, and add all Karaoke and ASS sign scripts. Then, pick your favorite lossless codec and encode everything to the equivalent of "Hayate-30-final.avi". Take a deep breather. Most of your pain is over now, and any reencodes required later than this point will be VERY fast.

9) Encoding the MKV and preparing the Softsub MKV

Assuming that you're releasing the MKV as softsub, you can _immediately_ proceed to encode the final version. Just stick the avs wrapper script for the -final.avi into MeGUI and encode away. You do NOT need to wait for any finalized scripts. Very convenient.

If you want to save time, you can also start to write the chapters file and prepare mmg for the final muxing, tagging all streams, adding the fonts etc.

10) Adding the dialogue script

So you've finally received the -RC or even -F dialogue script, depending on your group's setup. For the MKV, just make a ASS-SRT conversion if you do that, and add both the .ass and .srt script to mmg. Mux. Congrats, you just finished the first release candidate.

Before you upload it to your project FTP, I recommend that you open it in your player, check that all streams are properly tagged, and skip through the chapter markers to see that they all turn out okay. If they do, time to open the FTP client and push up the RC to the project dir.

Time to work on the AVI: Make a small avisynth wrapper which downscales the hi-res raw to the AVI resolution, load it in Virtualdub and add the dialogue script (or add it to the avisynth wrapper in the first place). Then, make a normal xvid 2-pass encode for the desired target size.

Finally, it's time to sit/lie down and proofwatch the entire MKV episode. If you happen to come across an error, fix it in the .ass (and .srt) scripts, remux the MKV and reupload the file. For the AVI, you only need to repeat the SECOND pass with the fixed .ass script. Usually the MKV upload takes longer than the second pass of the AVI, so you don't lose any time.

When the MKV seems to be all right, mux the now-finished AVI with the prepared audio in Virtualdubmod, save it to the target filename and upload it to the project FTP. It's a good idea to rewatch the episode in AVI once more, to make sure that no glitches popped up. Again, when errors show, just stop any upload, fix the error, remux the MKV, upload the MKV and reencode the second pass of the AVI. Since we're only working on lossless pre-encoded video, this can be done extremely quickly.

11) The RCs pass QC and are ready for release

Calculate the CRCs, add them to the RCs on the project FTP and notify the distro.

Done.

Last edited by Mentar; 2007-10-21 at 04:56. Reason: Fixing the numbering, Typo fixing
Mentar is offline   Reply With Quote
Old 2007-10-21, 15:57   Link #2
jfs
Aegisub dev
 
 
Join Date: Sep 2004
Location: Stockholm, Sweden
Age: 39
Quote:
Originally Posted by Mentar
If your timer is on a terrible line in Portugal, you can also create a "Crapraw" with quant 10 - easily downloaded, and it still has the keyframes he'll need for the Aegisub timing postprocessing later.
Actually not needed, Aegisub has for quite some time been able to read "keyframe files", ie. a text file that lists keyframes, those can even be loaded when no video is loaded. Since a short while ago it can even load XviD pass-files which also contain the keyframes information.
(If you load a video file that has keyframe information Aegisub understands, you are also able to save a keyframes file from inside Aegisub.)
__________________

Aegisub developer [ Forum | Manual | Feature requests | Bug reports | IRC ]
Don't ask for: More VSFilter changes (I won't), karaoke effects, help in PM's
jfs is offline   Reply With Quote
Old 2007-10-21, 16:20   Link #3
martino
makes no files now
 
 
Join Date: May 2006
Quote:
Originally Posted by Mentar View Post
Again, when errors show, just stop any upload, fix the error, remux the MKV, upload the MKV and reencode the second pass of the AVI. Since we're only working on lossless pre-encoded video, this can be done extremely quickly.
Is this safe to do? I mean re-using a 1st pass file for the 2nd pass which might have something minor different than whatever that was used originally? I know, it might be just "eror" changed to "error", a very small change albeit, however wouldn't this cause any problems, or are the changes generally just so small that it won't matter?

Nice HOWTO though for the ones that might be using some inefficient process or the ones who don't know how.


P.S. The only thing that I seem to do differently is that I always do the workraws in SD resolutions (even when there will be an HD release as well). I guess the main reason for this is that the workraw ends up being smaller and after all VSFilter just renders it to the input video resolution. As far as AFX goes the typesetter always re-encoded the needed sequence from the SD workraw to HD resolution himself and rendered it that way (well, not like it happened many times to be honest, but it did work). Never had any problems with it this way...

(Also I've been bad to everyone, using b-frames in workraws ^_-)
__________________
"Light and shadow don't battle each other, because they're two sides of the same coin"
martino is offline   Reply With Quote
Old 2007-10-21, 16:30   Link #4
ArabianSwan
Ureshii ^_^
 
 
Join Date: Jan 2006
Send a message via AIM to ArabianSwan
Quote:
Originally Posted by Mentar View Post
8) Putting it all together

Now it's time to create one more "final" lossless video. It should contain everything but the dialogue script.
The problem with this method, as I came across few times, is that not always the signs are final or good. For example, a translator will start with the dialogue, finish that and upload it. Next comes the signs script, and since he did them seperatly, if there is a sign that reads the same as the dialogue, they might not be exactly the same. Editor may not notice it as s/he does the same, edit each file seperatly. Only when it is up for QCing... they notice it.

For that few times it happened with me I decide to just go form pre-filtered to final xvid or x264 encoding
ArabianSwan is offline   Reply With Quote
Old 2007-10-21, 16:38   Link #5
ArchMageZeratuL
Aegisub dev
*IT Support
 
 
Join Date: Dec 2004
Location: Florianópolis, Brazil, Pale Blue Dot
Age: 38
Quote:
Originally Posted by martino View Post
Is this safe to do? I mean re-using a 1st pass file for the 2nd pass which might have something minor different than whatever that was used originally? I know, it might be just "eror" changed to "error", a very small change albeit, however wouldn't this cause any problems, or are the changes generally just so small that it won't matter?
Typically, hardsubs are only responsible for around 5-10% of the video bitrate. Remember that what matters in the first pass is how much detail there is in any given frame. Adding or removing a letter won't dramatically affect how much bitrate that frame needs... Even if it's a whole missing line, the change shouldn't be SO dramatic as to require a new first pass. At worst, you'll have that scene with slightly unbalanced bitrate, but most people would never notice that.

Quote:
Originally Posted by martino View Post
(Also I've been bad to everyone, using b-frames in workraws ^_-)
Actually, as far as I can tell, b-frames are safe AS LONG AS YOU ENABLE "Packed Bitstream". But if you want to be 100% safe, just don't use them. B-frames WITHOUT packed bitstream are a sure-fire recipe for disaster, though, unless you are encoding directly to mp4, and using something that can do frame-accurate seeking in it (i.e. the latest builds of aegisub with ffmpegsource support).

Quote:
Originally Posted by ArabianSwan View Post
The problem with this method, as I came across few times, is that not always the signs are final or good. For example, a translator will start with the dialogue, finish that and upload it. Next comes the signs script, and since he did them seperatly, if there is a sign that reads the same as the dialogue, they might not be exactly the same. Editor may not notice it as s/he does the same, edit each file seperatly. Only when it is up for QCing... they notice it.

For that few times it happened with me I decide to just go form pre-filtered to final xvid or x264 encoding
I too think that it's unnecessary to make a second lossless file. You can just encode all passes directly from a .avs... usually, subtitles don't take a significant amount of time to render, except for karaokes... But, again, I don't use After Effects, so the situation might be a bit trickier with that.

At any rate, great guide, Mentar.
ArchMageZeratuL is offline   Reply With Quote
Old 2007-10-21, 16:58   Link #6
Mentar
Banned
 
 
Join Date: Nov 2003
Location: Hamburg
Age: 54
Quote:
Originally Posted by martino View Post
Is this safe to do? I mean re-using a 1st pass file for the 2nd pass which might have something minor different than whatever that was used originally? I know, it might be just "eror" changed to "error", a very small change albeit, however wouldn't this cause any problems, or are the changes generally just so small that it won't matter?
That's so small it won't matter.

Quote:
P.S. The only thing that I seem to do differently is that I always do the workraws in SD resolutions (even when there will be an HD release as well). I guess the main reason for this is that the workraw ends up being smaller and after all VSFilter just renders it to the input video resolution. As far as AFX goes the typesetter always re-encoded the needed sequence from the SD workraw to HD resolution himself and rendered it that way (well, not like it happened many times to be honest, but it did work). Never had any problems with it this way...
Ugh, the typesetter upscales the SD workraw and then starts typesetting on the blurry mush? What's the point? ^_^; ... sorry, I'd definitely avoid this step which is error-prone AND problematic due to missing details (AFX sign with full replacement or fadeover, anyone?)

If you're really worried about the size, go to quant 3.5 or 4.
Mentar is offline   Reply With Quote
Old 2007-10-21, 17:03   Link #7
Mentar
Banned
 
 
Join Date: Nov 2003
Location: Hamburg
Age: 54
Quote:
Originally Posted by ArabianSwan View Post
The problem with this method, as I came across few times, is that not always the signs are final or good. For example, a translator will start with the dialogue, finish that and upload it. Next comes the signs script, and since he did them seperatly, if there is a sign that reads the same as the dialogue, they might not be exactly the same. Editor may not notice it as s/he does the same, edit each file seperatly. Only when it is up for QCing... they notice it.

For that few times it happened with me I decide to just go form pre-filtered to final xvid or x264 encoding
Well, signs are supposed to be final by then. That's why you're proofing them before ^_^; ... yes, sign errors are nasty, but they should happen rarely enough to justify step 8). And besides, I always keep the former only-prefiltered lossless too, so should a sign change later on, you can simply repeat the process.

If your signs are mostly ASS and you don't trust your colleagues too much, you can keep the signs out of it - however if you're working alot with AFX typesetting in a sign-rich environment, you usually do NOT want to do the overlays again for each pass. They DO slow down encoding significantly.
Mentar is offline   Reply With Quote
Old 2007-10-21, 17:10   Link #8
Mentar
Banned
 
 
Join Date: Nov 2003
Location: Hamburg
Age: 54
Quote:
Originally Posted by ArchMageZeratuL View Post
I too think that it's unnecessary to make a second lossless file. You can just encode all passes directly from a .avs... usually, subtitles don't take a significant amount of time to render, except for karaokes... But, again, I don't use After Effects, so the situation might be a bit trickier with that.
That's the thing. I've recently come across Karaokes which render at 0.6 fps on a Core2Duo E6700. I don't really want to multipass on those ^_^;

Besides - if there's something an encoder should have, then it's free diskspace. At least over all the years, I never had a shortage there.
Mentar is offline   Reply With Quote
Old 2007-10-21, 17:19   Link #9
martino
makes no files now
 
 
Join Date: May 2006
Quote:
Originally Posted by Mentar View Post
Ugh, the typesetter upscales the SD workraw and then starts typesetting on the blurry mush? What's the point? ^_^; ... sorry, I'd definitely avoid this step which is error-prone AND problematic due to missing details (AFX sign with full replacement or fadeover, anyone?)

If you're really worried about the size, go to quant 3.5 or 4.
Hehe. Everyone has their opinion.

I guess with signs that you mentioned there you do need the detail there, but if it is just a <sign here> <br> <tl here> it is enough in my opinion. (Hint: use your imagination when looking at the mush ^_^). That is, final point being, depending on how much typesetting the series would need and its complexity. That's I guess what I would base my choice of workraw resolution on...

Ah yes... Slow-rendering karaoke effects. Those are yummy. n_n

EDIT: I do also remember staff members not being too happy about a high resolution workraw and welcoming an SD one, but I guess that just depends on who you're working with...
__________________
"Light and shadow don't battle each other, because they're two sides of the same coin"
martino is offline   Reply With Quote
Old 2007-10-22, 00:43   Link #10
Nicholi
King of Hosers
 
Join Date: Dec 2005
Age: 41
Quote:
Originally Posted by martino
Is this safe to do? I mean re-using a 1st pass file for the 2nd pass which might have something minor different than whatever that was used originally? I know, it might be just "eror" changed to "error", a very small change albeit, however wouldn't this cause any problems, or are the changes generally just so small that it won't matter?
Instead of re-encoding the entire file (ugh, even if only for the 2nd pass) I've taken the habit of just re-encoding the nearest keyframe to keyframe with the fixed sign/whatnot. This way it doesn't take nearly as long and you should be done in only a few minutes (usually you won't have to re-encode more then a few 100 frames, unless you have to redo the entire OP/ED...which takes awhile but not as long as the entire file). You split the bad area in original file from the nearest keyframes and append in the fixed segment. Voila, good as new. You just have to be sure you correctly calculate the bitrate in the segment you will append so that it exactly matches the size of the one you split out. The bitrate calc in MeGUI is fairly accurate I've found, sometimes a little on the underside.

Quote:
Originally Posted by Mentar
That's the thing. I've recently come across Karaokes which render at 0.6 fps on a Core2Duo E6700. I don't really want to multipass on those ^_^;
Lulz all too true, though I'm not even on a Core2Duo . Lately I have been hardsubbing the OP/ED alone to separate lossless files and just Trimming them back into the video in the "final" avs. Again big time saver instead of rendering the entire file.

For some reason I've had a few karaokes that when combined rendering and encoding to x264 (and a large resolution) for some reason at times avisynth just gives out in the middle of the karaoke. After hours of waiting I get a shiny red warning avisynth frame in the output . Usually only happened when I put extra load on the CPU when it was encoding the karaoke section. Never did figure out what the true problem was, though I suspect VSFilter being evul!
Nicholi is offline   Reply With Quote
Old 2007-10-22, 07:26   Link #11
jfs
Aegisub dev
 
 
Join Date: Sep 2004
Location: Stockholm, Sweden
Age: 39
Quote:
Originally Posted by Nicholi View Post
For some reason I've had a few karaokes that when combined rendering and encoding to x264 (and a large resolution) for some reason at times avisynth just gives out in the middle of the karaoke. After hours of waiting I get a shiny red warning avisynth frame in the output . Usually only happened when I put extra load on the CPU when it was encoding the karaoke section. Never did figure out what the true problem was, though I suspect VSFilter being evul!
Hmm that sounds funny, I think it might not be exclusive to VSFilter or whatever, because I've had OverLua also fail badly when run directly in x264 - it seems it's only safe to run in VDub. These might be related, maybe even a bug in x264.
__________________

Aegisub developer [ Forum | Manual | Feature requests | Bug reports | IRC ]
Don't ask for: More VSFilter changes (I won't), karaoke effects, help in PM's
jfs is offline   Reply With Quote
Old 2007-10-22, 07:50   Link #12
edogawaconan
Hi
*Fansubber
 
 
Join Date: Aug 2006
Send a message via MSN to edogawaconan Send a message via Yahoo to edogawaconan
Quote:
Originally Posted by Mentar View Post
That's the thing. I've recently come across Karaokes which render at 0.6 fps on a Core2Duo E6700. I don't really want to multipass on those ^_^;
tell the kara fx maker to use \k only (or with some \fad )
anyway, nice howto - and I can see its use even for softsub-only or hardsub-only groups
__________________
edogawaconan is offline   Reply With Quote
Old 2007-10-22, 13:40   Link #13
Onniguru
 
Join Date: Feb 2006
This thread deserves a sticky

Quote:
Originally Posted by Mentar View Post
Virtualdub
Virtualdubmod
I'm using mkvmerge for my muxing...but thats only for mkv and mp4 muxing, of course.
Quote:
Avisynth 2.5.6a (you can try 2.5.7 if you want, I prefer the older version)
x264 with MeGUI
MKVtoolnix
Aegisub
Audio tools (Besweet, NeroAACenc, etc)
Quote:
Usually, most groups will have access to japanese P2P networks like Winny or Share and thus have access to various types of raws. 2) Loading the Video
Yeah I use SHARE too

Quote:
However, if you plan to release a h264 version, make sure you resize to mod16 - that's usually 704x400, 640x480, 1024x576, 1280x720.
704x400 is what I usually make.
There are some guides HERE that mention
If you are editing NTSC anamorphic 720x480 footage then you should make graphics at 848x480 and resize to 720x480. If you are editing PAL anamorphic 720x576 footage at then you should make graphics at 1024x576 and resize to 720x576.
This does not apply to folks grabbing stuff off of Winny or SHARE, of course, but to folks ripping DvDs only...
Example:
-------------------------------------------------------------------------------------------------------
# taicho 10/20/2007
LoadPlugin("C:\Program Files\AviSynth 2.5\plugins\DGDecode.dll")
# The above is important, seeing as I have 3 different versions of DGDecode.dll
# scattered around my system (AMVapp version, Gordian Knot version, Standalone latest build)
#LoadPlugin("C:\Program Files\AviSynth 2.5\plugins\DCTFilter.dll")
LoadPlugin("C:\Program Files\AviSynth 2.5\plugins\mt_masktools.dll")
LoadPlugin("C:\Program Files\AviSynth 2.5\plugins\RemoveGrainSSE2.dll")
MPEG2Source("D:\d2v\When_They_Cry\VTS_04_1.d2v", cpu=4)
deint = TDeint(mode=2, mtnmode=3, blim=100)
TFM(pp=6, cthresh=4, clip2=deint) #pp=0 while editing, change to pp=6 before exporting
TDecimate()
LanczosResize(848,480)
#Filtering comes after this, and despite being a direct DVD rip, boy did it need it...

--------------------------------------------------------------------------------------------------------
This is not the whole script of course...the filtering etc. begins after this point. Also, don't expect to ever find the mkv I'm making from this to ever show up on the internet, folks...I don't distribute DVD rips . This is for my own use only.
--------------------------------------------------------------------------------------------------------

Quote:
3) Audio extraction and preparation

There are several possibilities here. If your release contains audio in a form which you want to reuse "directly" without re-encoding it, you can just extract it via Virtualdub
Most of the files I get off of SHARE these days has audio that can't be read by Virtualdub . I extract it with Avidemux2, or I extract it with Virtualdubmod. To a wav file of course.

Orrrrrr....I extract the audio using megui, directly to whatever final form I want (usually AAC). If I'm in a hurry. Then I remux at the end of it all using mkvmerge.

Quote:
4) Filtering of the original raw

Filtering of raws, especially high-resolution raws, can be very very time-consuming
Here is some recent filtering I did...I hope its not terrbile, heh
# taicho 10/14/2007
LoadPlugin("C:\Program Files\AviSynth 2.5\plugins\mt_masktools.dll")
LoadPlugin("C:\Program Files\AviSynth 2.5\plugins\RemoveGrainSSE2.dll")
DirectShowSource("D:\animetemp\ShareDownload\higur ashi_kai_14_src_704x396.mp4",fps=23.976, convertFPS=true)
#TDecimate(mode=7, rate=23.976)
#AssumeFPS(23.976)
AddBorders(0,2,0,2)
LanczosResize(704,400)
# for some sources, but not h264 ones like this...
#deblock_qed( quant1=20,quant2=24, aOff1=2,bOff1=4,aOff2=4,bOff2=8 )
deblock(quant=30)
#sometimes used instead of undot+FluxsmoothT
#Deen("w3d",3,3,4)
Undot().FluxSmoothST(5,7)
LimitedSharpenFaster(ss_x=1.6, ss_y=1.6, strength=120, Lmode=2)
#BlockBuster(Method="Dither")
deblock(quant=20)

---------------------------------------------------------------------------------------------
This whole script took about 2.5 hours for two-pass x264 encode with Megui.
Of course, I have a dual processor, 3.2 ghz machine

Last edited by Onniguru; 2007-10-22 at 17:14.
Onniguru is offline   Reply With Quote
Old 2007-10-22, 15:19   Link #14
ArchMageZeratuL
Aegisub dev
*IT Support
 
 
Join Date: Dec 2004
Location: Florianópolis, Brazil, Pale Blue Dot
Age: 38
Why are you upscaling to 848x480, and before any crop, at that? Just crop 8 pixels on each side and leave it like that, making it anamorphic on the container. Also, if you're doing DVDs, you should be using Yatta, anyway.
ArchMageZeratuL is offline   Reply With Quote
Old 2007-10-22, 16:50   Link #15
Onniguru
 
Join Date: Feb 2006
Quote:
Originally Posted by ArchMageZeratuL View Post
Why are you upscaling to 848x480, and before any crop, at that? Just crop 8 pixels on each side and leave it like that, making it anamorphic on the container. Also, if you're doing DVDs, you should be using Yatta, anyway.
Did you not follow the link or read the extraction from A&E?

I'm just following their instructions...

If you are editing NTSC anamorphic 720x480 footage then you should make graphics at 848x480 and resize to 720x480. If you are editing PAL anamorphic 720x576 footage at then you should make graphics at 1024x576 and resize to 720x576.

This is from A&E official guide. If you don't like it, don't complain to me...complain to them, or have them change their guide.

Edit: just adding that, even this "beta" version of their guide is a couple years old, and they were writing toward encoding with XviD, not h264. As mentor has noted for me elsewhere, the best bet for state-of-the-art h264 encodes is to leave in crop 8 pixels each side, leave it animorphic at 704x480, and let the viewers player take care of the rest.

None the less, the approach written above was valid once-upon a time, or A&E would not have put it in their guide...
Onniguru is offline   Reply With Quote
Old 2007-10-22, 17:04   Link #16
ArchMageZeratuL
Aegisub dev
*IT Support
 
 
Join Date: Dec 2004
Location: Florianópolis, Brazil, Pale Blue Dot
Age: 38
I tried following the link, but it was broken and I was too lazy to fix it (even though the fix is trivial).

Anyway, having non-anamorphic was only valid in the pre-mkv days. Now that we can easily do anamorphic videos on any codec, you shouldn't hard resize a video to make it the proper aspect ratio.
ArchMageZeratuL is offline   Reply With Quote
Old 2007-10-23, 02:33   Link #17
Alizar
Junior Member
 
Join Date: Mar 2006
Quote:
Originally Posted by ArchMageZeratuL View Post
Anyway, having non-anamorphic was only valid in the pre-mkv days. Now that we can easily do anamorphic videos on any codec, you shouldn't hard resize a video to make it the proper aspect ratio.
Right, but you *do* need to make the video you're working against the proper AR if someone's doing an anamorphic encode. Several ways to do it, but because I've not futzed with PAR settings in AFX, I just make a comp of 853x480, stretch the video I'm working on, then squish the overlay back into anamorphic res. Since it's all rasterized, no loss of quality and no AR error on your typeset that's now been made anamorphic.

Edit: This is all assuming a 16:9 AR, of course.
Alizar is offline   Reply With Quote
Old 2007-10-23, 11:29   Link #18
jfs
Aegisub dev
 
 
Join Date: Sep 2004
Location: Stockholm, Sweden
Age: 39
Quote:
Originally Posted by Onniguru View Post
Did you not follow the link or read the extraction from A&E?

I'm just following their instructions...

If you are editing NTSC anamorphic 720x480 footage then you should make graphics at 848x480 and resize to 720x480. If you are editing PAL anamorphic 720x576 footage at then you should make graphics at 1024x576 and resize to 720x576.
What this says is that if you produce additional overlay graphics for the video, you should produce that graphics in the (approx.) 1:1 PAR format and then resample it to the non-1:1 PAR format, such that the aspect ratio of the overlays stays correct.
__________________

Aegisub developer [ Forum | Manual | Feature requests | Bug reports | IRC ]
Don't ask for: More VSFilter changes (I won't), karaoke effects, help in PM's
jfs is offline   Reply With Quote
Old 2007-10-23, 13:44   Link #19
Skyward
Oblivious
*Fansubber
 
Join Date: Jul 2007
Quote:
Originally Posted by jfs View Post
Quote:
Originally Posted by Onniguru View Post
Did you not follow the link or read the extraction from A&E?

I'm just following their instructions...

If you are editing NTSC anamorphic 720x480 footage then you should make graphics at 848x480 and resize to 720x480. If you are editing PAL anamorphic 720x576 footage at then you should make graphics at 1024x576 and resize to 720x576.
What this says is that if you produce additional overlay graphics for the video, you should produce that graphics in the (approx.) 1:1 PAR format and then resample it to the non-1:1 PAR format, such that the aspect ratio of the overlays stays correct.
That makes sense. However, if you are to edit at the approximate 1:1 PAR, wouldn't you resize it to 852x480 (assuming YUY2 and NTSC)? If you're just using it for editing and not the final product, you shouldn't need to worry too much about mod16 right?
Skyward is offline   Reply With Quote
Old 2007-10-23, 15:29   Link #20
jfs
Aegisub dev
 
 
Join Date: Sep 2004
Location: Stockholm, Sweden
Age: 39
Indeed, if I were to produce overlay graphics for video with non-1:1 PAR I would either draw it in the closest resolution possible before scaling down (ie. 853x480, because image editors rarely care about even MOD2 resolutions) or use an editor that supports non-1:1 PAR images, such as Photoshop.
__________________

Aegisub developer [ Forum | Manual | Feature requests | Bug reports | IRC ]
Don't ask for: More VSFilter changes (I won't), karaoke effects, help in PM's
jfs 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 21:50.


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