GSP
Quick Navigator

Search Site

Unix VPS
A - Starter
B - Basic
C - Preferred
D - Commercial
MPS - Dedicated
Previous VPSs
* Sign Up! *

Support
Contact Us
Online Help
Handbooks
Domain Status
Man Pages

FAQ
Virtual Servers
Pricing
Billing
Technical

Network
Facilities
Connectivity
Topology Map

Miscellaneous
Server Agreement
Year 2038
Credits
 

USA Flag

 

 

Man Pages


Manual Reference Pages  -  MP3CK (1)

NAME

mp3ck - MPEG stream consistency check

CONTENTS

Synopsis
Description
Diagnostics
Bugs

SYNOPSIS

mp3ck [-dhpqsv]

DESCRIPTION

The MPEG Layer 3 (MP3) format is widely used to exchange digital audio data over local networks and the Internet. Unfortunately, data transfers may be aborted due to various events in the network or at the local machine. Further, restarting an aborted transfer may corrupt data because of bugs in the software. It is often hard to tell by eye or ear whether an MP3 file that came from a third party had suffered from such a problem in the past.

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

Exit status is 0 if no errors occurred and no MPEG stream inconsistencies were found. Exit status is 1 if MPEG stream inconsistencies were found. What is considered an inconsistency can be affected by the -p option. Exit status is 2 if a file or system error occurred.

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 synchronizes to a stream at byte level despite MPEG streams being bit oriented. Byte level synchronization is sufficient for conventional MPEG audio files.

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?

Search for    or go to Top of page |  Section 1 |  Main Index


Powered by GSP Visit the GSP FreeBSD Man Page Interface.
Output converted with manServer 1.07.