<metadata name="ToolTip.TrayLocation" type="System.Drawing.Point, System.Drawing, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a">\r
<value>17, 17</value>\r
</metadata>\r
- <metadata name="ToolTip.TrayLocation" type="System.Drawing.Point, System.Drawing, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a">\r
- <value>17, 17</value>\r
- </metadata>\r
- <data name="slider_psyrd.ToolTip" xml:space="preserve">\r
- <value>Psychovisual Rate Distortion Optimization sure is a mouthful, isn't it? Basically, it means x264 tries to retain detail, for better quality to the human eye, \r
-as opposed to trying to maximize quality the way a computer understands it, through signal-to-noise ratios that have trouble telling apart fine detail and noise.</value>\r
- </data>\r
<data name="drop_adaptBFrames.ToolTip" xml:space="preserve">\r
- <value>When adaptive B-Frames are disabled, the number of B-Frames you specify is the constant length of every B-Frame sequence. \r
-When one of the adaptive modes is enabled, the number of B-Frames is treated as a maximum, with the length of each sequence varying, but never exceeding the max.\r
-\r
-Fast mode takes the same amount of time no matter how many B-frames you specify. However, it doesn't always make the best decisions on how many B-Frames to use in a sequence.\r
-\r
-Optimal mode gets slower as the maximum number of B-Frames increases, but does a much better job at deciding sequence length, which can mean smaller file sizes and better quality.</value>\r
+ <value>Bフレーム数の決定方法を指定します。\r
+「Off」に設定すると常に一定となり、Bフレーム数は「B-Frames」で設定した値になります。それ以外の値の場合、Bフレーム数は「B-Frames」で設定した値を上限として変動します。\r
+「Fast」に設定すると、「B-Frames」で設定した値に関わらずエンコード時間は一定となります。ただし、この場合状況によっては最適でないBフレーム数が選択される場合があります。\r
+「Optimal」に設定すると、より小さいサイズで高品位な値が決定されます。ただし、「B-Frames」で設定した値が大きくなるに従ってエンコードが遅くなります。</value>\r
</data>\r
<data name="check_Cabac.ToolTip" xml:space="preserve">\r
- <value>CABAC, or context adaptive binary arithmetic coding, is used by x264 to reduce the bitrate needed for a given quality by 15\%. \r
-This makes it very cool and very useful, and it should be left on whenever possible. However, it is incompatible with the iPod, and makes the AppleTV struggle. So turn it off for those.\r
-\r
-CABAC is a kind of entropy coding, which means that it compresses data by making shorthand symbols to represent long streams of data. The \"entropy\" part means that the symbols it uses the most often are the smallest. \r
-When you disable CABAC, another entropy coding scheme gets enabled, called CAVLC (context adaptive variable-length coding). \r
-CAVLC is a lot less efficient, which is why it needs 15\% more bitrate to achieve the same quality as CABAC.</value>\r
+ <value>このオプションをOnにするとCABAC（context adaptive binary arithmetic coding）が有効になり、映像品質はそのままでファイルサイズを約15％削減できます。\r
+この機能は非常に有用なので、できるだけOnにすることをおすすめします。\r
+ただし、iPodでの再生互換性に問題があるほか、AppleTVでの再生が難しくなるため、これらのデバイス用のファイルを作成する場合は無効にしてください。\r
+CABACはentropy codingの一種で、長いデータ列を記述するために短いシンボルを利用してデータを圧縮します。\r
+「entropy」は頻繁に使われるシンボルを最小にする、ということを意味しています。\r
+このオプションをOffにすると、CABACの代わりにCAVLC（context adaptive variable-length coding）と呼ばれるentropy coding方式が利用されます。\r
+CAVLSは効率の面ではCABACに劣っているため、同じ映像品質でもCABACを利用した場合と比べてビットレートが15％ほど増加します。</value>\r
</data>\r
<data name="check_noDCTDecimate.ToolTip" xml:space="preserve">\r
<value>To save space, x264 will \"zero out\" blocks when it thinks they won't be perceptible by the viewer. \r
It increases quality but also bitrate/file size, so if you use it when you've specified a target bitrate you will end up with a worse picture than without it. \r
However, when used with constant quality encoding, or if you boost the average bitrate to compensate, you might get a better result.</value>\r
</data>\r
- <data name="drop_trellis.ToolTip" xml:space="preserve">\r
- <value>Trellis fine-tunes how bitrate is doled out, so it can reduce file size/bitrate or increase quality. \r
-A value of 1 means it only fine-tunes the final encode of a block of pixels, while 2 means it is considered during earlier phases of the decision-making process as well.</value>\r
- </data>\r
<data name="drop_deblockBeta.ToolTip" xml:space="preserve">\r
<value>x264 includes an in-loop deblocking filter. What this means is that blocky compression artifacts are smoothed away when you play back the video. \r
It has two settings: strength and threshold, just like a simple filter in Photoshop.\r
Some prefer a slightly less blurred image for live action material, and use values like -2,-1 or -2,-2. Others will raise it to 1,1 or even 3,3 for animation. \r
While the values for each setting extend from -6 to 6, the consensus is that going below -3 or above 3 is worthless.</value>\r
</data>\r
- <data name="check_8x8DCT.ToolTip" xml:space="preserve">\r
- <value>Checking this box lets x264 break key frames down into 8x8 blocks of pixels for analysis. \r
-This is a high profile feature of H.264, which makes it less compatible. It should slightly decrease bitrate or improve quality. \r
-Turn it on whenever possible.</value>\r
- </data>\r
<data name="drop_analysis.ToolTip" xml:space="preserve">\r
<value>Analysis controls how finely x264 divides up a frame to capture detail. Full macroblocks are 16x16 pixels, but x264 can go down all the way to 4x4 blocks if it judges it necessary. \r
By default it only breaks up key frames that much. To give x264 the freedom to make the best decisions for all frames, use \"all\" analysis. \r
8 refines those decisions for I and P frames, and 9 adds on refinement for B-frames as well.</value>\r
</data>\r
<data name="drop_MotionEstimationRange.ToolTip" xml:space="preserve">\r
- <value>This range is the radius, in pixels, x264 should use for motion estimation searches. \r
-It only has an effect when you use Uneven Multi-Hexagonal, Exhaustive, or Transformed Exhaustive searching. \r
-24, 32, and 64 are good values, with each being progressively smaller for progressively less improvement to picture quality.</value>\r
+ <value>動き推定の対象範囲をピクセル単位で指定します。\r
+動き推定方式として「Uneven Multi-Hexagon」および「Exhaustive」、「Transformed Exhaustive」を指定している場合のみ有効です。\r
+24、32、64が適切な値です。値を小さくするほど、画質の向上は小さくなります。</value>\r
</data>\r
<data name="drop_MotionEstimationMethod.ToolTip" xml:space="preserve">\r
- <value>Controls the motion estimation method. \r
-Motion estimation is how the encoder decides how each block of pixels in a frame has moved, compared to most similar blocks in the other frames it references. \r
-There are many ways of finding the most similar blocks, with varying speeds and accuracy.\r
-\r
-At the most basic setting, dia, x264 will only consider a diamond-shaped region around each pixel.\r
-\r
-The default setting, hex, is similar to dia but uses a hexagon shape.\r
-\r
-Uneven multi-hexagon, umh, searches a number of different patterns across a wider area and thus is slower than hex and dia but further increases compression efficiency and quality.\r
-\r
-esa, an exhaustive search of a square around each pixel (whose size is controlled by the me-range parameter), is much slower and offers only minimal quality gains.\r
-\r
-tesa, transformed exhaustive search, which performs just as thorough a search, is slower still but offers further slight improvements to quality.</value>\r
- </data>\r
- <data name="check_pyrmidalBFrames.ToolTip" xml:space="preserve">\r
- <value>B-frame pyramids are a High Profile feature. Pyramidal B-frames mean that B-frames don't just reference surrounding reference frames - \r
-instead, it also treats a previous B-frame as a reference, improving quality/lowering bitrate at the expense of complexity. \r
-Logically, to reference an earlier B-frame, you must tell x264 to use at least 2 B-frames.</value>\r
- </data>\r
- <data name="check_weightedBFrames.ToolTip" xml:space="preserve">\r
- <value>Sometimes x264 will base a B-frame's motion compensation on frames both before and after. \r
-With weighted B-frames, the amount of influence each frame has is related to its distance from the frame being encoded, \r
-instead of both having equal influence. \r
-The AppleTV can have issues with this.</value>\r
+ <value>動き推定方式を指定します。\r
+動き推定とは、フレーム内のピクセルブロックがどのように動いたのかを決定するもので、参照フレームの中でもっとも「似ている」ブロックとの比較で決定されます。\r
+似ているブロックを見つける方法は精度や速度が異なる複数から選択できます。\r
+もっとも単純な設定は「Diamond」（ひし形）です。この設定では、それぞれのピクセルに隣接するピクセルのみを考慮します。\r
+デフォルトの設定である「Hexagon」（六角形）は「Diamond」に似ていますが、隣接ピクセルだけでなく周辺ピクセルも考慮します。\r
+「Uneven Multi-Hexagon」（umh）では、「Diamond」や「Hexagon」よりも広い範囲を対象に似ているブロックを検索します。より処理時間はかかるようになりますが、圧縮効率や品質は向上します。\r
+「Exhaustive」（esa）では、それぞれのピクセルの周囲一定範囲を網羅的に探索して似ているブロックを検索します。「Uneven Multi-Hexagon」よりもさらに低速で、品質向上は限定的です。\r
+「Transformed Exhausitive」はより徹底的に探索を行うオプションです。もっとも低速で、品質向上はわずかです。</value>\r
</data>\r
<data name="drop_directPrediction.ToolTip" xml:space="preserve">\r
- <value>Direct prediction tells x264 what method to use when guessing motion for certain parts of a B-frame. \r
-It can either look at other parts of the current frame (spatial) or compare against the following P-frameframe (temporal). \r
-You're best off setting this to automatic, so x264 decides which method is best on its own. \r
-Don't select none assuming it will be faster; instead it will take longer and look worse. If you're going to choose between spatial and temporal, spatial is usually better.</value>\r
+ <value>Bフレーム内のブロックに対してどのように動き予測を行うかを指定します。\r
+「Spatial」では、処理対象フレームのほかのブロックについても考慮します。\r
+「Temporal」では、続くPフレームと比較します。\r
+「Automatic」は自動的に最適な方法を選択します。「Automatic」が最適な設定です。\r
+「None」は選択しないことをおすすめします。予測を行わないため高速と思われがちですが、逆に低速になり、映像品質も悪化する可能性があります。\r
+なお、「Spatial」と「Temporal」では、通常は「Spatioal」のほうが高品質です。</value>\r
</data>\r
-</root>
\ No newline at end of file
+</root>\r
OSDN Git Service
