R.A. Epigonos et al.

[Streamripper] リッピングした Nullsoft Video (NSV) ファイルの編集

Streamripper は様々な方法を用いてデータを分割します。例えば、「メタデータを受信したらカット」や、「ミリ秒以上の空データでカット」等のことです。しかし、どの設定も、リッピングする内容や、サーバの環境によって、ターゲット固有の設定でなければなりません。全ての対象に対して同じ設定を使う事は設定しないこととほぼ同義です。しかし、対象に最も適した設定を見つけるまでは、サーバに対して接続と切断を繰り返し、満足の行く結果が得られるまで試行錯誤が必要です。

その結果、「対象に最適な固有の設定を見つける」というハードルが、「対象をリッピングをする」というゴールと摩り替わることがあります。最近は配信内容がころころ変わるサーバも見受けられますので、設定し終わったころには配信内容が変わっていたという事態も予想できます。ソフト使用者がほしいのはデータであって、設定では有りません。

データを手に入れた上で、その後見やすい形 (一話ごとにカット、CM 削除) に編集することこそが必要とされているのではないでしょうか。この章では既存のツールを使っていかに NSV ファイルを編集するかについて話を進めていきます。

NSV ファイルのデータ構造

NSV ファイルはヘッダに "NSVf" から始まるメタデータ、その後に "NSVs" から始まる AV (音声画像) データがいくつか続く。これらの区切り文字によって区切られたセクションをチャンクと呼ぶ。メタデータはファイル自体の情報 (再生時間、ファイルサイズ等) を記しているものなので、音声画像の再生だけでは、メタデータのある物と無いものの区別はつきません。つまり、無くても良いデータです。

従って AV データ部だけのファイルを作っても、データの再生は行われます。これに対し、メタデータのみのファイルは再生時間は表示されるものの、実際に再生が行われることはありません。また、メタデータのチャンクに書き込まれるデータは自己申告なので、たとえ此処に書かれている再生時間と、実際の再生時間の食い違いがあったとしても、AV データの再生時間が優先されます。

これまでのことによって、リッピングされたデータはどこで切断してもその前部分と後部分ともに、データ再生が可能であるということがいえる。ただし、再生できる (視聴できる) データは、ファイル内に書かれた最初の"NSVs"以降のデータで、これより前のデータは視聴できない。つまり、100MBytes のファイルでも内に "NSVs" が 1 つも見つからなければ、視聴できないファイルとなってしまうわけである。

NSV ファイルを切る (カット編集)

NSV ファイルはバイナリ形式である。従って、これを通常のエディタで開いてもまともに編集できない。その上、編集対象のファイルサイズが大きい場合、マシンによっては編集作業自体が重くなる。前者は、バイナリエディタを使うことで、後者は編集の前処理として対象の NSV ファイルを小さなピースに分割しておくことで解決される。

順番が逆転するが、後者から説明していく。ファイルを分割するソフトは Vector の "ファイル分割" を参照すれば多くある。著者が使ったものは「ファイル破断」というソフトである。これ以降はこのソフトを使った方法を紹介していく。その他にも多々あるので自分の使いやすいソフトを選べばいい。

まずはこのソフトを使ってファイルを 1MByte 程度のファイルに分割する。多くのソフトの場合、分割後のファイルは "元ファイル名. 3 桁の数字" の形である。また、同時に元ファイル復元を行うバッチファイルが同時に作成される。分割されたファイルのサイズがあまり大きい (100MByte-) とこの後に行う作業でマシンの動作が重くなる。また此処であまりに小さくすると (-100KByte)、"NSVs" が内部に含まれないため、内容の確認ができなくなる。

分割後の NSV ファイル確認 (カット編集)

次に分割後のファイルの確認を行う。分割後のファイルの拡張子は前述したように "3 桁の数字" である。このままでは Winamp で再生できないので、".nsv"を拡張子の後に追記する。("test.000"=>"test.000.nsv" 等) これで再生できるので、内容の確認が行える。Streamripper でリッピングした結果、"test.nsv"ができ、内容を確認すると以下のようになったとする。

分割ルール
元ファイル分割後内容
test.nsvtest.000.nsvCM
test.001.nsvCM&第一話
test.002.nsv第一話
test.004.nsv第一話
test.005.nsv第一話&CM
test.006.nsvCM&第二話
test.007.nsv第二話
test.008.nsv第二話
test.009.nsv第二話&CM
test.010.nsvCM
test.011.nsvCM&第三話
test.012.nsv第三話
test.013.nsv第三話
test.014.nsv第三話
test.bat復元用バッチファイル

確認後不要なファイルは削除してよい。上の例では test.000.nsv と test.010.nsv が不要。この様に分割された場合、test.001.nsv、test.005.nsv、 test.006.nsv、test.009.nsv、test.011.nsv はバイナリエディタで中身を確認しつつ分割する。これら不要な部分と必要な部分が両方含まれているファイルについては、後からバイナリエディタを使って不要な部分を削除するが、この作業が面倒な場合は、不要なファイルのみを削除して、バッチファイルを起動すれば、不要な部分の削除されたファイルが出来上がる。

NSV ファイルを一話ごとに分割 (カット編集)

内容ごとにフォルダを作成し、それらの内容が含まれているファイルのみを移動させる。その後、復元用バッチファイルをコピーして、作成した全てのフォルダに入れる。その後バッチファイルを起動させる。これで一和事のファイルが作成できた。

最後に原文を載せておきます。

始めに

ヌルソフト (多くのユーザーから支持されている、MP3 等の汎用マルチメディアプレイヤー Winamp の開発母体) はネットワーク配信を念頭に設計されたマルチメディアコンテナフォーマットを提供します。 このフォーマットは、ヌルソフトビデオと呼ばれ、拡張子は'.nsv'です

Description of the Nullsoft Video (NSV) Format
by Mike Melanson (melanson@pcisys.net)
v1.0: May 19, 2003
ヌルソフトビデオ(NSV)フォーマットについての記述
著者 マイク・ミーラソン(melanson@pcisys.net)
1.0版: 2003年3月19日
// some additions by Vitalijus Slavinskas, 2003.01.20
// 2003.01.23 finally understood toc structure //01.24 maybe not :D
  Copyright (c) 2003 Mike Melanson
  Permission is granted to copy, distribute and/or modify this document
  under the terms of the GNU Free Documentation License, Version 1.2
  or any later version published by the Free Software Foundation;
  with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts.
  A copy of the license is included in the section entitled "GNU
  Free Documentation License".
この文書を複製、出版、改変はGNUの公開文書規約1.2版、またそれ以降に出された版によって許可されています。
Contents
--------
 * Introduction
 * File Format
 * References
 * Acknowledgements
 * Changelog
 * GNU Free Documentation License
Introduction
------------
Nullsoft, the entity behind the ubiquitous Winamp MP3 / general-purpose
multimedia player, offers a multimedia container format designed with
network streaming in mind. The format is called Nullsoft Video and bears
the file extension '.nsv'.
File Format
-----------
All multi-byte numbers are in little endian format.
A NSV file has the following overall structure:
  'NSVf' optional metadata chunk
  'NSVs' audio/video data chunk
  [NSVs chunk]
    ..
  [NSVs chunk]
NSV files may start with an optional info and index chunk that is marked
by the characters 'NSVf'. The chunk has the following layout:
  bytes 0-3    'NSVf' signature
  bytes 4-7    size of chunk, including signature and size fields
  bytes 8-11   total size of file
  bytes 12-15  playtime in msec of file
  bytes 16-19  length of info strings
  bytes 20-23  number of table entries // number of nsvs*2+1
  bytes 24-27  number of table entries //number of nsvs
    [arbitrary length info string]
      ..
    [arbitrary length info string]
    [data table]
Following the first 28 bytes of the info block is any number of
arbitrary length info strings. The strings take the format of:
  STRING=`value`
The string is delimited by the backtick (`) character, a.k.a. ASCII
0x60. Known strings include TITLE and ASPECT for the NSV file's title
and aspect ratio, respectively. Examples:
  TITLE=`deer video`
  ASPECT=`1.125`
// IMHO only values are delimited and only with 0x01 (or how it's written in C)
// between tags is space 0x20
Following the metadata strings is a table of incrementing 32-bit
numbers. The number of entries in this table is specified in the NSVf
chunk header, apparently twice. The meaning of these numbers is unclear.
// it's offset's in data stream, they point to 'NSVs', maybe mark keyframes...
// later something called 'TOC2'
// and after this
// array of frame number in every nsvs
// this is valid for winamp genrated seek information, but encoding tools makes *something* :)
The meat of a NSV file (encoded audio and video chunks) is stored in a
series of NSVs data chunks. Each NSVs chunk can contain multiple video
and/or audio chunks.  A NSVs chunk has the following header:
  bytes 0-3    'NSVs' signature
  bytes 4-7    video codec fourcc
  bytes 8-11   audio codec fourcc
  bytes 12-13  video width, divisible by 16
  bytes 14-15  video height, divisible by 16
  byte 16      framerate
     bit 7     1 = lower 7 bits indicate a standard fractional framerate
               0 = lower 7 bits indicate an absolute framerate
     bits 6-0  framerate
  bytes 17-18  unknown
If a file does not have audio or video, the corresponding codec fourcc
will be 'NONE'. Common video fourccs are 'VP31' and 'VP3 ' which
indicate On2 VP3 video. Common audio fourccs are 'MP3 ' for MPEG layer
III audio and 'PCM ' for raw PCM audio.
The MSB of byte 16 appears to indicate that the lower 7 bits represent a
standard fractional framerate. For example, 0x81 equates to 29.97 fps,
0x85 equates to 14.98 fps, while 0x0F simply represents 15 fps.
PASCAL EXAMPLE:         // at least  i didn't know standart fractional framerate and such so it's clearer maybe
fr :byte;     // framerate
ft :whatever; // frametime msec
           if fr>$79 then
           begin
               case (fr and 3) of
                  0:dal:=3000;   // 30.00 baze
                  1:dal:=3003;   // 29.97
                  2:dal:=3600;   // 25.00
                  3:dal:=3753;   // 23.98
               end;
               if fr<$C0 then
                  ft := (dal * ((fr xor $80) shr 2 +1) ) div 90;
               else
                  ft := dal div (90 * ((fr xor $C0) shr 2 +1) );
           end
           else
               ft:=1000 div fr;
After the NSVs header are 5 bytes which provide the following length
information:
  v? vv vv aa aa
The lower nibble of byte 0 is unknown. The upper nibble of byte 0, along
with bytes 1 and 2 comprise the length of the video data in bytes. Since
there are 5 hex characters to describe the length, the maximum video
chunk size is 2^20 = 1 megabyte. Bytes 3-4 are the 16-bit length of the
audio chunk. Consider this example:
  80 B7 00 D1 00
The first 3 bytes, 80 B7 00, are rearranged in little endian form as
0x00B780. Then the number is shifted right by 4 to give a video chunk
length of 0xB78 bytes. The audio chunk length bytes are D1 00, or 0x00D1
in little endian.
After the first video/audio chunk pair in a NSV file, there will be a
BEEF marker before the next pair. That is, the hex number 0xBEEF encoded
in little endian (EF BE). After the marker is another 5 bytes encoding
the video and audio chunk lengths as described above, followed by
another frame of video and audio data. This BEEF-length-data pattern
continues until the end of the NSVs chunk.
A small note on PCM audio: If the audio data is encoded with fourcc
'PCM ', each audio data chunk will contain the following 4-byte header:
  byte 0      unknown
  byte 1      number of channels
  bytes 2-3   sample rate
// there should be added info about subtitles
// http://forums.winamp.com/showthread.php?s=a1811303139d1c1301779730986ada93&threadid=158106&highlight=subt
References
----------
NSV website, home to samples and SDK:
http://www.nullsoft.com/nsv/
Acknowledgements
----------------
Thanks to Roberto Togni (rtogni at bresciaonline dot it) and Arpad
"A'rpi" Gereoffy (arpi at mplayerhq dot hu) for further investigation
into the format.
Changelog
---------
v1.0: May 19, 2003
- sorted out NSVs chunk formatting
- document promoted to 1.0 status since enough information has been
uncovered to create functional demuxers
v0.2: March 13, 2003
- licensed under GNU Free Documentation License
- expanded information regarding NSVs data chunks
v0.1: February 11, 2003
- initial release
GNU Free Documentation License
------------------------------
see http://www.gnu.org/licenses/fdl.html

実用上は余分なデータをカット編集する事です。重要なことは

ソーシャルブックマーク

  1. はてなブックマーク
  2. Google Bookmarks
  3. del.icio.us

ChangeLog

  1. Posted: 2009-01-03T11:25:41+09:00
  2. Modified: 2009-01-03T07:52:18+09:00
  3. Generated: 2024-12-16T23:09:15+09:00