Content-type: text/html
mpgedit [-s] [-v[v[v[v[v]]]]] [-p] [-d N] [-e [start[-[end]]]] [-E] [-I] [-X[0|1|2]] [-L] [-l volume] [-f] input_file [-o [+]outfile_name ] mpgedit [-D] [-DbN] [-DcN] [-DmN] [-Ds] [-d N] input_file [input_file2 ...]
When editing a file, mpgedit locates the nearest MPEG frame boundary for the desired start and end times, then copies the frames between these times to the output file. Since no file decoding / encoding occurs during editing, there is no audio quality loss when editing with mpgedit. For each file being edited, a time index file is created that stores the file position, in bytes, for every 1 second of play time. Indexing guarantees correct and fast random access to edit time offsets for VBR-encoded files.
mpgedit file playback allows edit-time audio playback auditioning, which insures that desired cut occurs at the correct time offset. This feature is necessary when making edits that demand sub-second accuracy (especially with VBR files). Since most MP3 players display playback run times based on a VBR file's average encoded bit rate, edits based on these players' displayed times can miss the desired start or stop time by many seconds.
It is not necessary to use the playback functionality to make edits when the edit start and stop times are already known. The playback feature is merely an aid for accurately locating the desired edit start and stop times.
mpgedit operates in two modes: a command line and a curses-based, full-screen interactive shell. All editing functionality is available in both modes. The chief advantage of the interactive mode comes when using the playback feature for selection and verification of edit begin and end times, which is more rapidly performed interactively.
If multiple input files are specified, all -e options in a group apply to the -f immediately following a group of -e options. For example:
The -X1 modifies the input file's XING header in place. This is the one exceptional case when mpgedit modifies the input file.
The -X2 option generates a new file, containing the XING header prefix, followed by the contents of the input file. The output file is defaulted when the -o outfile option is not used. The default output file name is the same basename as the input file name, with the '_newxing_nn.mp3' extension, where nn is a unique integer extension.
This example illustrates the addition of a XING header to a file without this header:
This command generates the new file myfile_newxing_1.mp3, containing a XING header prefix, followed by the contents of the input file myfile.mp3
Note: Releases of mpgedit prior to 0.6p1 did not always properly update the Xing header after performing an edit. Using mpgedit 0.6p1, or later, these incorrect headers can be fixed with the following command:
Note: The addition of a XING header to a CBR file is possible with the -X2 option. Although harmless, the addition of a XING header to such a file is unnecessary, and redundant. However, when joining a CBR file followed a VBR file, the addition of a XING header becomes necessary in order for some MP3 players to properly display the elapsed run time.
Interactive mode uses single key commands to control editing functionality. Command key binding are similar to vi edit commands. Interactive mode has the following edit commands available:
For each of the start and end time input fields, the minute, second, and millisecond values can be modified. The desired numeric value can be directly input from the keyboard, or the current value can be modified by incrementing or decrementing the current value up with the . command and down with the , command.
Multiple input file names may be entered, separated by spaces or commas. When a comma separator is used, spaces loose their separator meaning. Use a comma separator makes entering multiple file names where spaces are part of the file name more convenient. Preceding a space character or a comma with a backslash (\) quotes that character, and it is no longer interpreted as a separator. The file named music,1.mp3 must be entered as music\,1.mp3, for example. The file Styx - Mr. Roboto.mp3 must be entered as Styx\ -\ Mr.\ Roboto.mp3 when the comma separator is not used, as each space would be interpreted as a separator.
mpgedit can edit a file automatically by searching for periods of silence in an input file. Each silent period found represents an edit that will be performed on the input file. The results of this editing analysis are stored in a saved session file named levels_session. This session file can be loaded for review in an mpgedit interactive curses session (see the L interactive mode command) or by xmpgedit (see the Load Session... section described in xmpgedit(1)). Specifying both the -D and -c command line options will load the automatic edits into an mpgedit interactive curses session. Automatic edit mode can be entered in an interactive curses session with the A command.
mpgedit automatic editing requires each input file be decoded into its PCM or .wav representation. This decoding is done only for the purposes of silence detection. Once the edit times for each silence boundary have been detected, all edits are performed on the original input files without decoding or re-encoding. The results of the input file decoding are stored in a corresponding input.lvl file. The .lvl file stores the average volume level for representative frames from the input file. By default, every 9th frame from the input file is decoded, corresponding to approximately 3 volume samples per second. This default may be changed by the -d N option. This skipping of frames is done for performance reasons, since decoding MP3 data to its PCM representation is a computationally expensive operation. For most applications, 3 audio samples per second is sufficient to accurately detect silence boundaries.
This is simplest automatic editing example:
These operations are performed by this command:
After this analysis is complete, load the levels_session file into mpgedit for review and further refinement of the edit start and stop times.
Sometimes it is necessary to override one or more of the parameters controlling silence detection. The mpgedit default values generally work for all content, but sometimes it is necessary to tweak these parameters to obtain the desired results.
This example reduces to 30 seconds the amount of time that must pass before a subsequent segment boundary can be detected. The silence threshold has also been reduced to -20db, allowing louder sections to be detected as a segment boundary.
These parameters control the silence detection analysis, modifying the sensitivity of the detection.
Cut the file test1.mp3 into 4 pieces. The first cut starts at the beginning of test1.mp3, and ends at 6 1/2 seconds; cut 2 begins at 6 1/2 seconds, and ends at 12 1/2 seconds; cut 3 begins at 12 1/2 seconds and ends at 19 seconds; cut 4 begins at 19 seconds and includes the remainder of test1.mp3.
Join four MP3 files together into a single output file. The edit time specification -e- means start from the beginning of the file and run through to the end of the file. In this example, only one edit time specification is needed, and is applied to all input file names that follow. Note the -f option can be omitted when the remainder of the command line is input file names.
This example joins cuts from two different files. The first cut is from output.mp3, start at 19 seconds and ending at the end of file. The second is from from test1.mp3, starting at the beginning of the file and ending at 6 1/2 seconds. The default output filename is used (output_1.mp3). The cuts from both input files are stored in output_1.mp3 because the first cut ends at the end of file and the second cut starts at the beginning of file.
Create 3 cuts, two from test1.mp3, one from test2.mp3. In this case, the default output file names are created, resulting in the three cuts stored in test1_1.mp3, test1_2.mp3, and test2_1.mp3, respectively.
Performs the same edits as the previous example, but saves the edit results in one output file, named edits.mp3.
Begin sound playback from the file song1.mp3 beginning 19 seconds into the file.
Parse MPEG audio file frames, and display frame information. This example demonstrates the output displayed when -vvv is used. For the purposes of this discussion, lines tagged with (1), (2) and (3) correspond to -v, -vv and -vvv respectively; the (1), (2) and (3) do not appear in the actual output.
Found xing header
h_id = 1
h_layer = 3
h_protect = 0
samprate = 44100
flags = 15
frames = 18146
bytes = 9238103
vbr_scale = 44
...
(1) *** t=1s fr=39 pos=22232 (0x56d8)
(2) MPEG header t=1.044s br=192 sz=626 fr=40 pos=22232 pos=0x56d8
(3) File position: 0 (0x0)
(3) Frame size: 626 (0x272)
(3) MPEG version: 3 (MPEG Version 1)
(3) MPEG layer: 1 (Layer III)
(3) Protection: 0 (no)
(3) bitrate: 11 (192)
(3) sample_rate: 0 (44100)
(3) Pad: 0 (no)
(3) Private: 0 (no)
(3) channel_mode: 1 (Joint stereo)
(3) joint_ext_mode: 0 (Intensity stereo off; Mid-side stereo off)
(3) Copyright: 0 (no)
(3) Original: 1 (yes)
(3) Emphasis: 0 (None)
...
File name: elgar.mp3
VBR Min: 80
VBR Max: 192
VBR Average: 150
Total frames: 15584
File size: 7623958
Track length: 6:47.85 (407s)
Variable Bit Rate frame statistics
Bit Rate Frame Count
-------------------------
80 kbps: 1 (<1%)
96 kbps: 27 (<1%)
112 kbps: 733 (4%)
128 kbps: 4169 (26%)
160 kbps: 10196 (65%)
192 kbps: 458 (2%)
The message Found xing header indicates the input file is a VBR encoded files with a XING ancillary data header. The only two fields updated by mpgedit are the frames (number of frames in encoding) and bytes (total encoding size in bytes) fields. h_id indicates the MPEG version; only 1=MPEG-1 is recognized. h_layer indicates the MPEG layer; valid values are 1, 2 and 3. h_protect is 1 when the copyright protection is enabled, and 0 when not enabled. samprate is the audio sample rate for the encoding, in hertz (Hz). Both flags and vbr_scale are values internal to the header.
When the -v option is used, only lines with the (1) tag in the example above are displayed. These lines are displayed for each one second of input file play time. t= is the time offset into the input file. fr= is the frame number for this time offset. The file position in bytes (in both decimal and hexadecimal formats) follows pos=.
When the -vv option is used, lines with the (2) tag are displayed in addition to the (1) tag. One (2) line is displayed for each frame present in the MPEG input file. t= is the time offset into the input file, and is displayed with 1 millisecond resolution. br= is the frame encoding bitrate, in kb/s. sz= is the frame size, in bytes. fr= is the frame number for this time offset. pos= is the file position in bytes,displayed in both decimal and hexadecimal formats.
When the -vvv option is used, lines with the (3) tag are displayed in addition to the (1) and (2) tags. These additional lines display all information contained within an MPEG frame, and are displayed for each frame present in the file. Each value is identified by name, followed by the un-interpreted value, followed by the interpreted value, appearing within parentheses.
For all -v options listed above, a summary is printed after the entire file is read. For CBR encoded files, the file name, frame count, file size and play time are displayed. For VBR encoded files, the frame minimum, maximum, and average encoding bitrate is displayed, in addition to the CBR summary. Furthermore, for VBR encoded files, a summary of the total number of frames encoded for each bitrate present in the input file is displayed.
Sound playback is implemented using two mechanisms: 1) an external command line MP3 player capable of standard input file playback, and 2) the MPGLIB decoder library that ships with the LAME project. The default playback configuration uses the MPGLIB-based decoder plugin libdecoder_mpg123.so.
Two decoder plugin implementations ship with mpgedit: libdecoder_popen.so and libdecoder_mpg123.so. libdecoder_popen.so will execute the mp3decoder.sh script for file playback. libdecoder_mpg123.so is implemented using the MPGLIB decoder library present in LAME. This implementation also serves as a sample implementation of a single process playback plugin that could be ported to the Microsoft Windows(R) operating systems, and other operating systems that do not support the popen() system call.
mpgedit attempts to load the playback plugin libmpgedit_decoder.so when file playback is specified. When the decoder plugin is loaded, it is used for file playback. When the decoder plugin cannot be loaded, the default action is to execute the mp3decoder.sh script.
libmpgedit_decoder.so is installed as a symbolic link pointing to one of the playback plugins, libdecoder_mpg123.so or libdecoder_popen.so. make install installs the libdecoder_mpg123.so playback plugin. libdecoder_popen.so can be installed manually when use of a command line MP3 player is desired.
To use a different command line MP3 player, configure libdecoder_popen.so as the playback plugin, then edit the mp3decoder.sh file to call the desired MP3 player. This shell script is then loaded by mpgedit when performing file playback, and provides the flexibility to specify any MP3 player that can play files from standard input.
While it is possible with mpgedit to join together files that consist of differing encoding versions (MPEG-1 and MPEG-2, for example) and sample rates (44.1KHz and 22.05KHz, for example), caution must be used. Although such a file is technically a legal encoding, it is doubtful that all (or any, for that matter) MP3 players will be able to correctly render such a file.
Any ID3 tags present in input files are not present in the output from an edit. Output files must be tagged to restore ID3 information.
mpgedit implements an MPEG audio frame header parser that is tolerant of many encoder errors, corrupted data, and files with formats that are not strictly MPEG audio files. When such an encoding error is encountered, all data between the last correctly encoded frame and the next recognized frame are silently skipped. Other programs, such as mp3_check, perform a more detailed validity check and report where errors occur, and are likely to be more robust when handling corrupted data files.
Many playback problems present in releases of mpgedit prior to version 0.6p1 have been fixed. Using the libdecoder_mpg123.so plugin, mpgedit properly plays all of the ISO MPEG conformance files, as well as MPEG 2/2.5 files encoded using lame. Two exceptions to the above can be noted. Win32 does not properly handle MPEG 2/2.5 files encoded at with a sample rate of 11025Hz/mono. A work around in the libdecoder_mpg123.so decoder plugin is implemented, but the sound quality suffers. The MPEG 1 layer 1 mono test file http://mpgedit.org/mpgedit/testdata/mpeg1/layer1/fl4.mp1 does not render properly. All the data used to exercise mpgedit is located at http://mpgedit.org/mpgedit/testdata/mpegdata.html.
During development, the previous name of the program was mp3edit. The final name mpgedit was settled on after much development occurred. Because of this, many source files and function names are called mp3_. You will also see mpeg_ instead of mpg_ in some cases.
mpgedit is a completely independent implementation from the early mp3_check editing prototype. While some of the early ideas from this prototype still exist in mpgedit, everything has been re-implemented.
Finding reference material sufficiently complete to implement mpgedit was difficult. The O'Reilly & Associates book "MP3: The Definitive Guide" by Scot Hacker http://www.oreilly.com/catalog/mp3/, while accurate in its description of the MPEG audio file frame header structure, did not contain sufficient detail to fully implement the MPEG file parsing functionality. The document that proved invaluable for completing the MPEG audio frame header parsing code was written by Predrag Supurovic, http://www.dv.co.yu/mpgscript/mpeghdr.htm.
The MPGLIB decoding engine comes from the MPG123 package, written by Michael Hipp (www.mpg123.de). MPGLIB is released under the GPL. The version of MPGLIB used for building the libdecoder_mpg123.so decoder plugin comes from the 3.90 alpha 7 version of LAME http://sourceforge.net/projects/lame. Earlier versions of LAME do not include a shared library build of MPGLIB, which is needed when building the decoder plugin. The MPGLIB that comes with mpg123-0.59r can also be used when linking the libdecoder_mpg123.so plugin. However, LAME appears to have fixed some bugs that mpg123 has not.
Special thanks go to Jared Benedict <http://redjar.org/jared/> and Public Radio Exchange <http://www.prx.org/> for the donation of a Macintosh G3 B&W computer. Completion of the port to Mac OSX 10.3 was possible using this system.
The initial port of the command line and curses mpgedit to Mac OSX 10.1 was done with thanks to Tony Andrea <tony.andrea@pobox.com>.
Thanks to Colin Bell <cpb@tklogic.net> for helping with freshing the Mac OSX 10.1 port.