NAME

SYNOPSIS

DESCRIPTION

The mp3ck utility can check the consistency of an MPEG Layer 2 or 3 stream. The primary accent of the check is on the seamless flow of frames and tags since most MPEG defects introduced by aborted network transfers manifest theirselves in breakage of the flow.

The following options are available:

-d

Ultimate verbosity. Besides all possible warnings and per-file information, messages will be printed for every frame or tag processed.

-h

Print a short help message and exit.

-p

Be pedantic about MPEG stream inconsistencies. See the list of detected inconsistencies for details.

-q

Decrease verbosity by one level. If specified once, warnings about trailing junk will be suppressed. If specified twice, it will currently be equivalent to the -s option.

-s

Be silent completely.

-t

Try to print time offsets (MM:SS) instead of byte offsets in diagnostic messages. In a couple of messages, offsets may still be in bytes though.

-v

Increase verbosity by one level. If specified once, per-file information about MPEG parameters will be printed. If specified twice, it will currently be equivalent to the -d option.

DIAGNOSTICS

The following MPEG stream inconsistencies are detected:

empty file

A MPEG stream appeared to be of zero length.

no audio frames

A byte stream contained no valid MPEG frames. This error is likely to appear if mp3ck was invoked on a non-MPEG file.

leading junk

A MPEG stream did not begin with a valid frame or ID3 tag. In the case of a file, this is usually a sign of corruption, e.g., due to a poorly resumed transfer over a network when the beginning of the stream was lost.

trailing junk

A MPEG stream was consistent (unless other warnings were issued), but some random bytes appeared after its last frame. This is mostly harmless and may be caused by an unaligned ID3v1 tag or some sort of application-specific data. No MPEG stream inconsistency will be reported in exit status unless the -p option was specified.

trailing junk (truncated ID3v%c tag?)

The same as above, but there were only one or two extra bytes that looked like the beginning of an ID3 tag. "I", "ID", "T", and "TA" are the possible values for the bytes.

last frame incomplete

unexpected EOF at frame header+n

ID3v%c tag incomplete

These are the most common defects seen in MPEG files. They appear when an aborted transfer over a network remains unnoticed. However, a uniform or slightly varying number of bytes missing from the last frame over a series of files is usually just a sign of a quirk of the MPEG encoder/tagger used.

sync after %ld bytes of junk

Normal flow of MPEG frames and ID3v2 tags was broken and then resumed after a portion of random bytes. Such a defect is likely to appear if a network transfer was resumed poorly. In particular, many Windows FTP clients tend to lose data when resuming an FTP upload because they fail to determine how many bytes have been delivered to the remote side successfully. On the other hand, such a warning appearing after an ID3v2 tag is often harmless and just indicates non-compliant padding of the tag.

ID3v1 in the middle of the file

An ID3v1 tag should not appear in the middle of a MPEG stream. An obscure corruption of the stream is likely to have happened.

ID3v2.%d.%d unsupported

A MPEG stream contained an ID3v2 tag, but its major version was not recognized. Since the ID3v2 standard is still under development, its future versions may introduce features incompatible with former specifications. An unsupported ID3v2 tag is just skipped as junk bytes.

Additionally, a number of invalid MPEG header field values are detected and reported accordingly.

BUGS

The mp3ck utility cannot check Layer 1 streams.

ID3 tags are accepted in a Layer 2 stream.

A CRC check of MPEG headers is not implemented yet.

This manpage fails to distinguish files from streams. Can you?