Code:
==========================
2. Modes that create files
==========================
Currently, the modes that create output files are fix, join, split, strip,
conv, and pad. These modes are highly configurable in terms of the output files
they can produce. All of these modes support the following command-line options
(with the exception of conv mode, which does not support -p):
-o format (specifies output format, where format may be wav, shn, etc.)
-O action (specifies whether output files should be overwritten if they
exist - action must be 'ask', 'always' (default) or 'never')
-d dir (specifies an alternate output directory than the default)
-p (preview changes without actually making them)
NOTE: Be aware that some output format encoder programs (e.g. flac, ape)
automatically strip headers and/or extra RIFF chunks, while others
(e.g. sox) might adjust WAVE data sizes in rare instances in order to
align the audio on a block boundary.
------------
2a. fix mode
------------
The purpose of fix mode is to take a set of input files that contain CD-quality
WAVE data and rewrite them so that they are properly aligned on a sector
boundary. It does this in one of three ways - it shifts track breaks backward
to the previous multiple of 2352 bytes whenever necessary, shifts track breaks
forward to the next multiple of 2352 bytes whenever necessary, or rounds track
breaks to the nearest multiple of 2352 bytes whenever necessary. The default
action is to shift track breaks backward (though this may change to rounding
after it has been sufficiently tested, since this method minimizes the amount of
shifting performed). The desired shift may be specified with the '-s'
command-line switch.
Given a set of files to correct, fix mode will start its fixing at the first
file that has a sector-boundary error. This is intended to eliminate redundancy
and minimize the total amount of work done. For example, consider the following
set of files:
% shntool len *.shn
length expanded size cdr WAVE problems filename
2:59.54 31702652 --- -- ---xx ph91-07-15d2t01.shn
10:03.65 106522124 --- -- ---xx ph91-07-15d2t02.shn
5:08.23 54385340 --- -- ---xx ph91-07-15d2t03.shn
6:10.00 65268044 --- -- ---xx ph91-07-15d2t04.shn
4:46.43 50551300 -b- -- ---xx ph91-07-15d2t05.shn
8:29.39 89879372 --- -- ---xx ph91-07-15d2t06.shn
6:18.41 66775676 --- -- ---xx ph91-07-15d2t07.shn
1:35.53 16882436 -b- -- ---xx ph91-07-15d2t08.shn
45:32.18 481966944 B (totals for 8 files, 0.5567 overall compression ratio)
%
If you attempt to fix these files via 'shntool fix *.shn' or similar, then fix
mode will skip the first four files because they would not be changed (from a
WAVE data perspective). If you want to force it to operate on all files
regardless of whether they would be modified, then use the '-noskip'
command-line switch.
By default, the last file will be padded with zero-bytes up to the next multiple
of 2352 bytes, if necessary. This can be disabled via the '-nopad' option.
Output files will be named based on the corresponding input file, with "-fixed"
appended to the base part of the file name. By default, output files are
created in the current directory, unless told otherwise via the '-d'
command-line switch.
Here is sample output from fix mode when run on the above files:
% shntool fix *.shn
shntool [fix]: warning: no output format specified - assuming wav
shntool [fix]: warning: no shift direction specified - assuming backward shift
shntool [fix]: warning: skipping first 4 files because they would not be changed
ph91-07-15d2t05.shn --> ph91-07-15d2t05-fixed.wav ... done.
ph91-07-15d2t06.shn --> ph91-07-15d2t06-fixed.wav ... done.
ph91-07-15d2t07.shn --> ph91-07-15d2t07-fixed.wav ... done.
ph91-07-15d2t08.shn --> ph91-07-15d2t08-fixed.wav ... done.
Padded 'ph91-07-15d2t08-fixed.wav' with 544 zero-bytes.
%
Here is sample output exhibiting several different options:
% shntool fix -o shn -s r -d /mnt/audio/tmp -nopad -noskip *.shn
ph91-07-15d2t01.shn --> /mnt/audio/tmp/ph91-07-15d2t01-fixed.shn ... done.
ph91-07-15d2t02.shn --> /mnt/audio/tmp/ph91-07-15d2t02-fixed.shn ... done.
ph91-07-15d2t03.shn --> /mnt/audio/tmp/ph91-07-15d2t03-fixed.shn ... done.
ph91-07-15d2t04.shn --> /mnt/audio/tmp/ph91-07-15d2t04-fixed.shn ... done.
ph91-07-15d2t05.shn --> /mnt/audio/tmp/ph91-07-15d2t05-fixed.shn ... done.
ph91-07-15d2t06.shn --> /mnt/audio/tmp/ph91-07-15d2t06-fixed.shn ... done.
ph91-07-15d2t07.shn --> /mnt/audio/tmp/ph91-07-15d2t07-fixed.shn ... done.
ph91-07-15d2t08.shn --> /mnt/audio/tmp/ph91-07-15d2t08-fixed.shn ... done.
File '/mnt/audio/tmp/ph91-07-15d2t08-fixed.shn' was not padded, though it needs 544 bytes of padding.
%
Here is a sample showing the preview capability:
% shntool fix -o wav -d ../disc1 -p -noskip *.wav
shntool [fix]: warning: no shift direction specified - assuming backward shift
Preview of changes:
-------------------
Track breaks will be shifted backward when necessary.
track1.wav --> ../disc1/track1-fixed.wav
- beginning of track will remain unchanged
- data size will remain unchanged
track10.wav --> ../disc1/track10-fixed.wav
- beginning of track will remain unchanged
- data size will remain unchanged
track2.wav --> ../disc1/track2-fixed.wav
- beginning of track will remain unchanged
- data size will remain unchanged
track3.wav --> ../disc1/track3-fixed.wav
- beginning of track will remain unchanged
- data size will remain unchanged
track4.wav --> ../disc1/track4-fixed.wav
- beginning of track will remain unchanged
- data size will remain unchanged
track5.wav --> ../disc1/track5-fixed.wav
- beginning of track will remain unchanged
- data size will decrease by 2072 bytes
track6.wav --> ../disc1/track6-fixed.wav
- beginning of track will be moved backward by 2072 bytes
- data size will remain unchanged
track7.wav --> ../disc1/track7-fixed.wav
- beginning of track will be moved backward by 2072 bytes
- data size will remain unchanged
track8.wav --> ../disc1/track8-fixed.wav
- beginning of track will be moved backward by 2072 bytes
- data size will increase by 264 bytes
track9.wav --> ../disc1/track9-fixed.wav
- beginning of track will be moved backward by 1808 bytes
- data size will increase by 1808 bytes
The last file '../disc1/track9-fixed.wav' would be padded with 544 zero-bytes.
%
The above example shows the usefulness of the '-order' switch, which allows you
to edit the order in which the files will be processed. Using the online
editor, you can fix the list so that track 10 properly appears after track 9,
instead of after track 1. This is usually simpler than specifying each track in
the correct order on the command line, although in the above case you can put
files in the correct order with:
% shntool fix -o wav -d ../disc1 -p -noskip track?.wav track??.wav
One final note on fix mode. If you have a single track that is not properly
sector-aligned, and you want to shift the track break backward (i.e. truncate
the extra data, rather than pad it), then you are out of luck because fix mode
will not let you do this. There is a workaround, though. Simply use a second
dummy file (such as 1 second of silence), and run fix mode with backward shift
on both files. When you are done, discard the second fixed file (the dummy
file) and the file you are left with will be your original file, truncated to
the previous sector boundary. Here is an example:
% shntool fix -s b -nopad badfile.wav dummy.wav
shntool [fix]: warning: no output format specified - assuming wav
badfile.wav --> badfile-fixed.wav ... done.
dummy.wav --> dummy-fixed.wav ... done.
File 'dummy-fixed.wav' was not padded, though it needs 1956 bytes of padding.
% shntool len badfile.wav badfile-fixed.wav
length expanded size cdr WAVE problems filename
2:46.21 29332232 -b- -- ----- badfile.wav
2:46.21 29331836 --- -- ----- badfile-fixed.wav
5:32.42 58664068 B (totals for 2 files, 1.0000 overall compression ratio)
%
Notice that badfile-fixed.wav is now the backward-shifted (truncated) version of
badfile.wav, which is what we wanted. Now remove 'dummy-fixed.wav', and you're
done.
-------------
2b. join mode
-------------
The purpose of join mode is to concatenate WAVE data from multiple files into
one output file. This can be useful if you want to completely retrack a show,
not just fix sector boundary problems. Note that all input files must have the
same WAVE format, number of channels, samples per second, bits per sample and
rate - otherwise shntool can't join them. If all input files are CD-quality,
then by default the output file will be post-padded with zero-bytes up to the
next multiple of 2352 bytes, if necessary. If you want to pre-pad the file
instead, use the '-prepad' option. If no padding is desired, use the '-nopad'
option. Unless you use the '-stdout' option, the output file will be named
'joined.ext', where 'ext' is the extension of the output file format. It will
be created in the current directory unless told otherwise via the '-d'
command-line switch. The default output format is 'wav' for unmodified builds
of shntool. Below is a sample of what you will see if you join mode with no
options:
% shntool join *.shn
shntool [join]: warning: no output format specified - assuming wav
Adding contents of gd73-03-24d3t01.shn to joined.wav ... done.
Adding contents of gd73-03-24d3t02.shn to joined.wav ... done.
Adding contents of gd73-03-24d3t03.shn to joined.wav ... done.
Adding contents of gd73-03-24d3t04.shn to joined.wav ... done.
Adding contents of gd73-03-24d3t05.shn to joined.wav ... done.
Adding contents of gd73-03-24d3t06.shn to joined.wav ... done.
Adding contents of gd73-03-24d3t07.shn to joined.wav ... done.
No padding needed for 'joined.wav'.
%
Here is an example using -stdout to pipe to another process:
% shntool join -stdout disc?/*.shn | lame - > stretch93-10-15.mp3 2>/dev/null
shntool [join]: warning: no output format specified - assuming wav
Adding contents of disc1/stretch93-10-15d1t01.shn to stdout ... done.
Adding contents of disc1/stretch93-10-15d1t02.shn to stdout ... done.
Adding contents of disc1/stretch93-10-15d1t03.shn to stdout ... done.
(many lines snipped for brevity)
Adding contents of disc3/stretch93-10-15d3t11.shn to stdout ... done.
Adding contents of disc3/stretch93-10-15d3t12.shn to stdout ... done.
Adding contents of disc3/stretch93-10-15d3t13.shn to stdout ... done.
No padding needed for 'stdout'.
%
Here is an example that exhibits several options:
% shntool join -d /mnt/audio/tmp -o shn -nopad *.wav
Adding contents of test01.wav to /mnt/audio/tmp/joined.shn ... done.
Adding contents of test02.wav to /mnt/audio/tmp/joined.shn ... done.
Adding contents of test03.wav to /mnt/audio/tmp/joined.shn ... done.
Adding contents of test04.wav to /mnt/audio/tmp/joined.shn ... done.
Adding contents of test05.wav to /mnt/audio/tmp/joined.shn ... done.
File 'joined.shn' was not padded, though it needs 1844 bytes of padding.
%
Here are a couple of samples showing the preview capability:
% shntool join -p doh.wav doh.wav
Preview of changes:
-------------------
WAVE data from the following files:
doh.wav
doh.wav
will be joined into file 'joined.wav', in the order shown above.
Padding would not apply to these files because they are not CD-quality.
%
% shntool join -p -d /mnt/audio/tmp -o wav *.wav
Preview of changes:
-------------------
WAVE data from the following files:
test1.wav
test10.wav
test11.wav
test12.wav
test2.wav
test3.wav
test4.wav
test5.wav
test6.wav
test7.wav
test8.wav
test9.wav
will be joined into file '/mnt/audio/tmp/joined.wav', in the order shown above.
This file wouldn't be padded, but would need 2176 bytes of padding.
%
The above example shows the usefulness of the '-order' switch, which allows you
to edit the order in which the files will be processed. Using the online
editor, you can fix the list so that tracks 10 through 12 properly appear after
track 9. This is usually simpler than specifying each track in the correct
order on the command line, although in the above case you can put files in the
correct order with:
% shntool join -d /mnt/audio/tmp -o wav test?.wav test??.wav
--------------
2c. split mode
--------------
The purpose of split mode is to create multiple files from a single input file.
Track breaks are defined by split points, which can be in any of the following
formats:
bytes (explicit byte offset from beginning of WAVE data)
m:ss (standard minutes:seconds format)
m:ss.ff (minutes:seconds.frames format, where a frame is 1/75 of a second)
m:ss.nnn (minutes:seconds.milliseconds format)
CUE sheet (simple CUE sheet format)
NOTE: m:ss.ff can only be used with CD-quality input files.
NOTE: CUE sheets MUST have the "FILE" keyword on the first line in order to be
properly recognized as a CUE sheet by shntool. From the second line on,
split points are recognized as lines which contain the "INDEX 01" keyword,
but NOT the comment keyword "REM". The m:ss:ff values on such lines are
parsed and internally converted to m:ss.ff split points. There is no
checking done to ensure that "TRACK" numbers are sequential. I do not
know whether this works for all possible permutations of a CUE sheet
(other than ones that don't have the "FILE" keyword on the first line of
course), so unless you use a CUE sheet generated by cue mode, there are no
guarantees that your files will be split correctly. Consult the cue mode
section above to see how it generates CUE sheets.
All of the above formats (except for bytes) are converted to byte offsets. If
the input file is CD-quality, then the byte offsets are rounded to the nearest
sector boundary. If you want to force non-sector aligned track boundaries, use
the explicit byte offset format.
NOTE: for CD-quality input files, if m:ss.nnn rounded to the nearest sector
boundary happens to be the beginning of the file, then it is rounded up to
the first sector boundary. Because of this, certain sequences of split
points will generate an error, even though they seem to be correct.
However, this is extremely unlikely to happen to you, unless you have two
split points within the first 0:00.020 of the file. ;-)
Split points can be read from standard input, from a file, or via the '-f' or
'-l' command-line switches. If the '-l' option is given, then the file will be
split into smaller files based on multiples of the given time interval;
otherwise, split points must be given in increasing order, and must not go
beyond the size of the WAVE data in the input file. If the first and/or last
split point's calculated byte offset falls at the very beginning and/or end of
the input file's WAVE data respectively, then it is ignored.
In the following examples, the contents of the split points files are shown for
reference.
Here is a sample invocation of split mode with repeated, same-sized split points:
% shntool split -l 72:00 bigfile.wav
shntool [split]: warning: no output format specified - assuming wav
Input file 'bigfile.wav' is being split into 3 pieces.
Writing split-track001.wav (72:00.00) ... done.
Writing split-track002.wav (72:00.00) ... done.
Writing split-track003.wav (67:13.45) ... done.
%
And another sample, with various split points:
% cat offsets1
0:13.25
0:26.50
0:40.00
0:53.25
1:06.50
1:20.00
1:33.25
1:46.50
% shntool split test.wav < offsets1
shntool [split]: warning: no output format specified - assuming wav
Input file 'test.wav' is being split into 9 pieces.
Writing split-track001.wav (0:13.25) ... done.
Writing split-track002.wav (0:13.25) ... done.
Writing split-track003.wav (0:13.25) ... done.
Writing split-track004.wav (0:13.25) ... done.
Writing split-track005.wav (0:13.25) ... done.
Writing split-track006.wav (0:13.25) ... done.
Writing split-track007.wav (0:13.25) ... done.
Writing split-track008.wav (0:13.25) ... done.
Writing split-track009.wav (0:04.74) ... done.
%
% cat offsets2
FILE "<anything can go here>" WAVE
TRACK 01 AUDIO
INDEX 01 0:00:00
TRACK 02 AUDIO
INDEX 01 6:04:67
TRACK 03 AUDIO
INDEX 01 14:06:19
% shntool split -o flac test.shn < offsets2
shntool [split]: warning: discarding initial zero-valued split point
Input file 'test.shn' is being split into 3 pieces.
Writing split-track001.flac (6:04.67) ... done.
Writing split-track002.flac (8:01.27) ... done.
Writing split-track003.flac (10:40.08) ... done.
%
You can change aspects of the output file names via the '-n' and '-c'
command-line switches:
% cat offsets3
0:13.333
0:26.667
0:40.000
0:53.333
1:06.667
1:20.000
1:33.333
1:46.667
% shntool split -o shn -f offsets3 -n mytest -c 7 test.wav
shntool [split]: warning: rounding 0:13.333 (offset: 2351941) to nearest sector boundary (offset: 2352000)
shntool [split]: warning: rounding 0:26.667 (offset: 4704059) to nearest sector boundary (offset: 4704000)
shntool [split]: warning: rounding 0:53.333 (offset: 9407941) to nearest sector boundary (offset: 9408000)
shntool [split]: warning: rounding 1:06.667 (offset: 11760059) to nearest sector boundary (offset: 11760000)
shntool [split]: warning: rounding 1:33.333 (offset: 16463941) to nearest sector boundary (offset: 16464000)
shntool [split]: warning: rounding 1:46.667 (offset: 18816059) to nearest sector boundary (offset: 18816000)
Input file 'test.wav' is being split into 9 pieces.
Writing mytest007.shn (0:13.25) ... done.
Writing mytest008.shn (0:13.25) ... done.
Writing mytest009.shn (0:13.25) ... done.
Writing mytest010.shn (0:13.25) ... done.
Writing mytest011.shn (0:13.25) ... done.
Writing mytest012.shn (0:13.25) ... done.
Writing mytest013.shn (0:13.25) ... done.
Writing mytest014.shn (0:13.25) ... done.
Writing mytest015.shn (0:04.74) ... done.
%
Finally, you can preview what changes would be made before actually making them
with the '-p' switch:
% cat offsets4
0:13
4704001
0:40.00
0:53.333
11760000
% shntool split -d /mnt/audio/tmp -p -n output_ -c 0 test.wav < offsets4
shntool [split]: warning: no output format specified - assuming wav
shntool [split]: warning: file 2 will not be cut on a sector boundary
shntool [split]: warning: file 3 will not be cut on a sector boundary
shntool [split]: warning: rounding 0:53.333 (offset: 9407941) to nearest sector boundary (offset: 9408000)
Preview of changes:
-------------------
File 'test.wav' will be split into 6 pieces:
+ /mnt/audio/tmp/output_000.wav (0:13.00)
- this file will contain 2293200 bytes of WAVE data (plus 44-byte header)
+ /mnt/audio/tmp/output_001.wav (0:13.50)
- this file will contain 2410801 bytes of WAVE data (plus 44-byte header)
- this file will not be cut on a sector boundary
+ /mnt/audio/tmp/output_002.wav (0:13.25)
- this file will contain 2351999 bytes of WAVE data (plus 44-byte header)
- this file will not be cut on a sector boundary
+ /mnt/audio/tmp/output_003.wav (0:13.25)
- this file will contain 2352000 bytes of WAVE data (plus 44-byte header)
+ /mnt/audio/tmp/output_004.wav (0:13.25)
- this file will contain 2352000 bytes of WAVE data (plus 44-byte header)
+ /mnt/audio/tmp/output_005.wav (0:44.74)
- this file will contain 7935648 bytes of WAVE data (plus 44-byte header)
%
--------------
2d. strip mode
--------------
The purpose of strip mode is to remove extraneous data from files. It has the
ability to shrink WAVE headers down to the canonical 44-byte header, and also to
remove extra RIFF chunks from the end of WAVE streams, which usually contain
miscellaneous information about the program used to create or edit the WAVE data
in that file. Since neither having a non-canonical header nor containing extra
RIFF chunks are harmful in and of themselves, it is usually not necessary to use
this mode. The only time you may want to use it is when you encounter a program
that cannot load a particular WAVE file because it expects it to have a
canonical header and/or expects that nothing follows the 'data' chunk in the
WAVE stream.
NOTE: Be aware that some output format encoder programs (e.g. flac, ape)
automatically strip headers and/or extra RIFF chunks, while others
(e.g. sox) might adjust WAVE data sizes in rare instances in order to
align the audio on a block boundary.
By default, headers are canonicalized, and extra RIFF chunks are stripped. You
can disable one or the other of these actions via the '-nh' (no header) and
'-nr' (no RIFF chunks) switches. Output files will be named based on the
corresponding input file, with "-stripped" appended to the base part of the file
name. By default, output files are created in the same directory as the
corresponding input file, unless told otherwise via the '-d' command-line
switch. File names are read from the command line, or from standard input if
none are specified on the command line. Here is a sample run of strip mode:
% shntool strip a.wav tms.shn
shntool [strip]: warning: no output format specified - assuming wav
a.wav --> a-stripped.wav ... done.
tms.shn --> tms-stripped.wav ... done.
%
You can preview what would be done with the '-p' switch (note the use of the
'-d' and '-o' switches as well):
% shntool strip -o shn -p -d /mnt/audio/tmp a.wav p2.wav
Preview of changes:
-------------------
a.wav --> /mnt/audio/tmp/a-stripped.shn
- will rewrite 46-byte WAVE header to the canonical 44-byte header
- will strip 1 byte worth of extra RIFF chunk(s) from the end of this file
p2.wav --> /mnt/audio/tmp/p2-stripped.shn
- will strip 827 bytes worth of extra RIFF chunk(s) from the end of this file
%
Here is what happens when you run strip mode on the above files, but specify not
to strip extra RIFF chunks:
% shntool strip -o shn -d /mnt/audio/tmp -nr a.wav p2.wav
a.wav --> /mnt/audio/tmp/a-stripped.shn ... done.
shntool [strip]: warning: file 'p2.wav' already has a canonical header - skipping.
%
-------------
2e. conv mode
-------------
The purpose of conv mode is to convert a set of input files to a specified
output format. File names are read from the command line; if none are given,
file names are read from standard input. If the input file name matches the
output file name, that file is skipped so that the input file isn't accidentally
overwritten. You can avoid file name clashes altogether by using the '-d'
option to specify an alternate ouput directory.
Output files are named based on the input file name. Specifically, if the input
file name ends with the default file extension for that file's format, then the
default extension for the desired output format will replace it; otherwise, the
default extension for the desired output format will be appended to it. For
example, for an output format of shn and a wav input file named 'file.wav', the
converted file will be named 'file.shn', since '.wav' is shntool's default
extension for the wav format. On the other hand, given the same situation
above, but with an input file named 'file.wave', the converted file will be
named 'file.wave.shn', since '.wave' does not match '.wav'.
NOTE: Be aware that some output format encoder programs (e.g. flac, ape)
automatically strip headers and/or extra RIFF chunks, while others
(e.g. sox) might adjust WAVE data sizes in rare instances in order to
align the audio on a block boundary.
By default, output files are created in the same directory as the input file.
This can be altered with the -d switch.
Here is one way to convert a set of SHN files to FLAC:
% shntool conv -o flac *.shn
converting 'gd73-03-24d3t01.shn' to 'gd73-03-24d3t01.flac' ... done.
converting 'gd73-03-24d3t02.shn' to 'gd73-03-24d3t02.flac' ... done.
converting 'gd73-03-24d3t03.shn' to 'gd73-03-24d3t03.flac' ... done.
converting 'gd73-03-24d3t04.shn' to 'gd73-03-24d3t04.flac' ... done.
converting 'gd73-03-24d3t05.shn' to 'gd73-03-24d3t05.flac' ... done.
converting 'gd73-03-24d3t06.shn' to 'gd73-03-24d3t06.flac' ... done.
converting 'gd73-03-24d3t07.shn' to 'gd73-03-24d3t07.flac' ... done.
%
Here is an example that converts files in different directories, placing the
output files in a specified directory:
% find gd72-08-27 -name \*.shn | shntool conv -o aiff -d tmp
converting 'gd72-08-27/disc1/gd72-08-27d1t01.shn' to 'tmp/gd72-08-27d1t01.aiff' ... done.
converting 'gd72-08-27/disc1/gd72-08-27d1t02.shn' to 'tmp/gd72-08-27d1t02.aiff' ... done.
converting 'gd72-08-27/disc1/gd72-08-27d1t03.shn' to 'tmp/gd72-08-27d1t03.aiff' ... done.
(many lines snipped for brevity)
converting 'gd72-08-27/disc3/gd72-08-27d3t05.shn' to 'tmp/gd72-08-27d3t05.aiff' ... done.
converting 'gd72-08-27/disc3/gd72-08-27d3t06.shn' to 'tmp/gd72-08-27d3t06.aiff' ... done.
converting 'gd72-08-27/disc3/gd72-08-27d3t07.shn' to 'tmp/gd72-08-27d3t07.aiff' ... done.
%
Here is an example with many different input file formats, as well as
non-standard file extensions:
% shntool conv example*
shntool [conv]: warning: no output format specified - assuming wav
converting 'example1.aiff' to 'example1.wav' ... done.
converting 'example2.ape' to 'example2.wav' ... done.
converting 'example3.flac' to 'example3.wav' ... done.
converting 'example4.shn' to 'example4.wav' ... done.
converting 'example5.ofr' to 'example5.wav' ... done.
converting 'example6.pac' to 'example6.wav' ... done.
converting 'example7.unknown' to 'example7.unknown.wav' ... done.
%
An unintended use for conv mode is to verify that files are not truncated,
by converting files to the 'null' output format. This output format simply
discards any data it receives, so it doesn't create any output files.
Examples are below.
Here is sample output for an intact, non-truncated file:
% shntool conv -o null test.shn
converting 'test.shn' to 'test.null (actually /dev/null)' ... done.
%
Here is sample output for a truncated file:
% shntool conv -o null truncated.shn
converting 'truncated.shn' to 'truncated.null (actually /dev/null)' ...
shntool [conv]: warning: tried to read 76496 bytes, but only read 75776 - possible truncated/corrupt file
shntool [conv]: warning: error while transferring 23931600-byte data chunk - skipping.
%
-------------
2f. pad mode
-------------
The purpose of pad mode is to individually pad files that are not aligned on
a sector boundary. This is NOT intended to be a replacement for fix mode!
It is provided to make padding easier for those who know what they are doing.
Files are padded at the end by default. Use the '-prepad' or '-postpad'
options to control where the file gets padded. To see what changes would be
made without actually making them, use the '-p' option.
Output files are named based on the input file name, with the string
"-prepadded" or "-postpadded" appended to the end, and the extension is the
default extension of the output file format.
NOTE: Be aware that some output format encoder programs (e.g. flac, ape)
automatically strip headers and/or extra RIFF chunks.
For instance, suppose you have a disc's worth of files in which only the first
file is not cut on a sector boundary. In this situation, some people would
prefer to add silence to the beginning of the first track in order to align it
on a sector boundary, instead of fixing every file in the whole set. Here is
an example of this:
% shntool len *.shn
length expanded size cdr WAVE problems filename
1:17.33 13660388 -b- -- ---xx grisman-rice95-04-30t01.shn
2:33.01 26991596 --- -- ---xx grisman-rice95-04-30t02.shn
2:56.14 31079372 --- -- ---xx grisman-rice95-04-30t03.shn
2:19.46 24627836 --- -- ---xx grisman-rice95-04-30t04.shn
5:23.73 57148940 --- -- ---xx grisman-rice95-04-30t05.shn
3:36.39 38194172 --- -- ---xx grisman-rice95-04-30t06.shn
5:36.45 59376284 --- -- ---xx grisman-rice95-04-30t07.shn
4:16.37 45245468 --- -- ---xx grisman-rice95-04-30t08.shn
3:11.01 33694796 --- -- ---xx grisman-rice95-04-30t09.shn
0:47.64 8441372 --- -- ---xx grisman-rice95-04-30t10.shn
5:03.42 53548028 --- -- ---xx grisman-rice95-04-30t11.shn
4:43.58 50057660 --- -- ---xx grisman-rice95-04-30t12.shn
6:30.50 68913644 --- -- ---xx grisman-rice95-04-30t13.shn
6:25.17 67954028 --- -- ---xx grisman-rice95-04-30t14.shn
4:29.30 47522204 --- -- ---xx grisman-rice95-04-30t15.shn
59:11.25 626455788 B (totals for 15 files, 0.6050 overall compression ratio)
% shntool pad -prepad -o shn grisman-rice95-04-30t01.shn
pre-padding 'grisman-rice95-04-30t01.shn' as 'grisman-rice95-04-30t01-prepadded.shn' with 72 zero-bytes ... done.
% shntool len grisman-rice95-04-30t01-prepadded.shn
length expanded size cdr WAVE problems filename
1:17.33 13660460 --- -- ---xx grisman-rice95-04-30t01-prepadded.shn
1:17.33 13660460 B (total for 1 file, 0.5335 overall compression ratio)
%
At this point you can replace the original file with the pre-padded file to
have a complete set of sector-aligned files.