The Validity of MD5 Checksums - Page 4

Five · #46 2020-02-15, 10:45 PM

burning an audio cdr with Feurio! without those annoying two second gaps. I think its called TAO gaps, tutorial circa 2000-12-09

I had to do something similar with Nero back in the day. I burned audio cdrs for personal use only not for trading. Attached .gif is from the old Feurio! homepage, classic.

Quote:

Originally Posted by etree.org

etree.org | feurio! introduction

Feurio! is a software program designed for creating audio CD-R's on PC's using Windows 95/98/Me and Windows NT/2000. You may use Feurio! for as long as you like without registering, without the software becoming crippled or any features becoming disabled. The only difference between the unregistered and registered versions of Feurio! are a few nag windows that will pop-up reminding you to register.

This page contains many graphics and may take a few seconds to load completely, depending on your Internet connection speed. Please be patient!

For more information about Feurio!, we suggest you visit the Official Feurio! website.

etree.org | feurio! download

To download the most recent version of Feurio!, go to the Official Feurio! English Download Page

etree.org | feurio! installation

Before installation, be sure to turn off or disable any virus protection software you may be using.
Click the Feurio! Download link above
When the "File Download" window appears, choose "Run this program from it's current location."
Note to Netscape users: If you are only given the option to save the setup program, save it to your desktop, then launch it by double-clicking.

[image missing]
The Feurio! installation program will now be downloaded to your PC.

[image missing]
You will receive a Security Warning window after the Feurio! installation program downloads. This is normal, and is nothing to be concerned about.
Click the "Yes" button to continue the installation.

[image missing]
Continue through the Feurio! installation process. When you are finished, you will see the screen below.

[image missing]
Now, fill out as much information about yourself as you feel comfortable. When you're finished, click the "Demo" button. Feurio! will now begin. Remember, you may use Feurio! as long as you like, without the software becoming crippled or any features becoming disabled (or having it insert annoying "nag" messages in the audio, like some other burning software. The only difference between the unregistered and registered versions of Feurio! are a few nag windows that pop-up reminding you to register.

[image missing]
If you'd like to register Feurio!, visit Feurio!'s registration page.

etree.org | feurio! config

Launch Feurio! from "Start > Programs > Feurio! > Feurio! CD-Manager"

[image missing]
The first time you start Feurio!, you will see a few configuration warning windows. Most Windows 98, Me, and 2000 users need not worry. Follow the "Don't remind me again" prompts to disable those annoying warning messages and then click "OK".

[image missing]
You will now see the main Feurio! window. See the usage instructions below.

etree.org | feurio! usage - basic

Open the Feurio! program.
You will see three main windows. On the left-hand side is the larger frame. This is called the Copy Source frame, and has three tabs at the top of it, labeled "CD-ROM", "Database"" and "Harddisc". You want to click on the "Harddisk" tab, since this is where the WAV files you want to burn to CD-R are located.
Browse to the location (drive and folder) of the WAV files you want to burn to CD-R. You want to make sure the WAV files are showing, similar to the example below.

[image missing]
Note: To expand (show the contents of) a drive or folder, click on the plus sign to the left of the drive or folder. It will then show it's contents, and the plus will turn into a minus.
Once you can see the WAV files you want to burn to CD-R, hold down the CONTROL button on your keyboard, and select the files you wish to burn. Release the CONTROL button when you're finished. The WAV files should be selected, similar to the example below.

[image missing]
Now, drag these files to the lower right-hand frame (this frame should be labeled "Project: Various - New Project"). It should look similar to the example below.

[image missing]
Make sure the tracks are in the correct order in the lower left-hand frame ("Project: Various - New Project" frame).
Click on the "Settings" button in the upper right-hand frame (it's next to the "Burn" button). A dialog box will appear.

[image missing]
Make sure the "Do not insert pauses between tracks - round track markers" is selected (first line), otherwise Feurio! may insert a two second gap in between each track.
Click "OK"
Now, click on the "Burn" button in the upper right-hand frame.

[image missing]
The burner dialog box will now pop up (you are using an unregistered version of Feurio!, you will see the nag screen first).
Click on the "Write" button, then click the "Burn CD" button. See the example below.

[image missing]
Please remember, these are very, very basic instructions to a process that is actually quite involved. We encourage you read the documentation at the Official Feurio! Website to better understand how Feurio! works.

etree.org | feurio! usage - advanced

For advanced usage information for Feurio!, we strongly suggest you take a look at the Official Feurio! Webpage.

etree.org | feurio! credits

Thanks to Fangmeier Systemprogrammierung, the creator of Feurio! This page written and maintained by Mike Wren. Please email mikew at etree.org with comments or suggestions.

Five · #47 2020-02-16, 12:25 AM

md5sum command line tool. .ffp/.st5 checksums required and preferred since 2005

Quote:

Originally Posted by etree.org

etree.org | md5sum.exe introduction

After you download all the Shorten (.shn) files for a particular disc or show, you want to verify that the files are not corrupted or otherwise unusable before you burn them to disc or host them on your file server. We do this by checking the downloaded Shorten (.shn) files against an .md5 file. An .md5 is a simple text file that contains a "fingerprint" of each Shorten file.

When you perform an md5 check, you are comparing the fingerprint from the files you downloaded to the fingerprint of the files on the server you downloaded from. If the md5's (fingerprints) match, you have an uncorrupted Shorten file.

etree.org | md5sum.exe download

md5sum.exe - 48KB 1243 Downloads since 9/29/00

etree.org | md5sum.exe installation

Windows 95/98/Me: Download md5sum.exe to c:\windows\command
Windows NT/2000: Download md5sum.exe to your c:\winnt\system32

etree.org | md5sum.exe usage, checking

Open an MS-DOS window and go to the directory of the show you want to check. When you are in that directory, type:

md5sum -c [filename].md5

You must insert the name of the .md5 file [without the brackets]. Below is an example of a successful md5sum check:

[image missing]

On the other hand, if a track does not pass the md5check, you will see the following:

[image missing]

If any Shorten files do not pass the .md5 check, you should delete the offending file(s), and try re-downloading. Then run the .md5 check again. The file(s) should now pass the .md5 check.

If the same files fail an .md5 check more than twice, you should contact the FTP Siteop you downloaded the files from and let them know what tracks are giving you a problem. They may be hosting a corrupted track without knowing it.

etree.org | md5sum.exe usage, creating

Open an MS-DOS window and go to the directory of the show you want to create an .md5 file for. When you are in that directory, type:

md5sum *.shn > [filename].md5

NOTE: You must insert the name of the .md5 file [without the brackets]. Example:

md5sum *.shn > ph94-06-26d1.md5

An .md5 file will be created and placed in that directory. Please remember to adhere the etree.org naming scheme when naming .md5 files!

etree.org | md5sum.exe etcetera

Please remember to always .md5 check your Shorten files before burning!

etree.org | md5sum.exe credits

Special thanks to brucexxxxxxxxxx.xxx and the PCP community for compiling this special version of md5sum. Documentation and graphics by Mike Wren.

legacy software documentation md5sum.txt

Code:

Usage: md5sum [OPTION] [FILE]...
  or:  md5sum [OPTION] --check [FILE]
Print or check MD5 checksums.
With no FILE, or when FILE is -, read standard input.

  -b, --binary            read files in binary mode
  -c, --check             check MD5 sums against given list

The following two options are useful only when verifying checksums:
      --status            don't output anything, status code shows success
  -w, --warn              warn about improperly formated MD5 checksum lines

      --help              display this help and exit
      --version           output version information and exit

The sums are computed as described in RFC 1321.  When checking, the input
should be a former output of this program.  The default mode is to print
a line with checksum, a character indicating type (`*' for binary, ` ' for
text), and name for each FILE.

WARNING:  You are using a specially adapted copy of md5sum.  This version
          has been modified as follows:
          1) Only ever use binary mode
          2) Be more liberal about line endings in files used by --check
          3) Built-in Win32 file wildcard matching (globbing)
          This version was compiled by brucexxxxxxxxxx.xxx for the
          People for a Clearer Phish.  Source code changes are available
          from Bruce upon request.


Report bugs to brucexxxxxxxxxx.xxx

Code:

--version
md5sum (PCP patchlevel 2) (GNU textutils) 1.22
eb574b236133e60c989c6f472f07827b *md5sum.exe

Five · #48 2020-02-16, 01:52 AM

shntool credits.txt

Code:

Thanks go to the following people, in no particular order:

Tim [tmo], whose ideas prompted the creation of this program's predecessor
(shnlen), and whose diligent testing helped iron out the bugs in that program.

Herschel Gelman, who had the great suggestion that shnlen could check to see
whether the .wav files inside the .shn's were properly cut on sector boundaries.
He also suggested that join mode could write to stdout, so that large amounts of
data could be piped into an external program, such as an mp3 encoder.

Caleb Epstein, for sending patches and helping to debug shntool, as well as
providing documentation and binary packages.  Also, for reporting the fix mode
hang, as well as providing a set of files that helped me reproduce it.
Additionally, for suggesting that info mode could tell whether .shn files were
seekable.

Jeff Kempka, for helping me obtain unruly files to aid in figuring out a rare
bug in the 0.9x series, as well as usability suggestions.

Bill Bumgarner, for suggesting that shntool move to GNU autoconf.  I learned a
lot in the process.  :^)

Paul Mather, for reporting bugs and compilation problems on platforms on which I
currently have no access, as well as testing and verifying their respective
fixes.  Also, for reporting the m:ss.ff rounding bug, as well as providing a
detailed analysis of the problem which expedited its fix.

Mike Kelleher, for contributing toward the design of split mode, as well as
helping to test it.

Mike Vernal, for providing the impetus (and nearly the code) to support AIFF, as
well as testing it.

Scott Brown, for putting the AIFF support through the wringer, helping to iron
out the kinks.  Also, for informing me that sox 12.17.4 now supports sowt-
compressed AIFF-C files.

jelly, for suggesting that join mode be able to join non-CD quality files.

Michael Dougherty, for reporting a bug where shntool would inadvertently include
extra RIFF chunks when calculating audio MD5 fingerprints.

Christian Weisgerber, who provided a Makefile patch.

Boogie Shafer, who was the first to suggest that shntool should support CUE
sheets.  Also, for the idea that split mode could split a file based on multiples
of a given time interval.  Finally, for enduring and reporting a seriously nasty
data-destroying bug in conv mode, which led to the implementation of file clobber
checks and the eventual instatement of 'ask' as the default overwrite action. :-/

John Cook, who was the first of several to ask for the ability to prepad files.
Also, for suggesting that shntool generate split points from an existing set of
files, and for suggesting that info mode show the sector-misalignment of
CD-quality files.

David Loehr, who was the first to report a set of files that could not be read
by shntool, which turned out to be caused by the existence of ID3v2 tags.
These tags are now skipped by shntool, leaving it up to external decoder
programs to handle them.

deep_elem, who reported a situation in which split mode would round extremely
small split points (0:00.001 - 0:00.020) to 0, causing shntool to error out.

Tim Ebben, whose keen eye noticed that the m:ss.ff value on the totals line was
reporting an incorrect value.

Greg Eriksen, for suggesting that shntool have an option not to add predefined
strings (e.g. "-fixed") to files.  This led to the ability to specify arbitrary
user-defined prefixes and postfixes.  Also, for suggesting that md5 mode allow
file reordering, for use with composite md5s.

M Blake, who was the first of several people to request the ability to trim
leading and/or trailing silence from files.

Dave Maley, who didn't like that split mode moved to a three-digit numbering
scheme (split-track001.wav, ...).  This led to the ability to specify your own
number format, in printf syntax (e.g. "%02d").

Krzysiek Wojszko, whose CUE file tripped up split mode so badly that I decided
I better try to support the whole CUE specification.  :)

Mike Harder, who reported a bug in split mode that prevented extremely large
files from being split correctly when using the -l option.

Michael Barnes, for contributing a patch to support natural filename sorting, and
for the idea that shntool can better utilize exit codes.

John, for suggesting that split mode be able to name output files based on TITLE
keywords in CUE sheets.

rob, for reporting a bug that prevented shntool from processing filenames read
from stdin under Windows.

Pierre-Yves, for offering to contribute code to name output files in split mode
based on several fields in CUE sheets.

David Bonde, for suggesting that split mode support user-defined lead-in and/or
lead-out.

Wim Speekenbrink, for reporting a bug where the last line of a CUE sheet that
lacks a newline character was not getting parsed in split mode.

Samson, for reporting a WavPack format detection issue and working with me to
discover the cause, which turned out to be a bug triggered by 64-bit systems.
Also, for providing me with sample CUE sheets that helped make split mode's
CUE sheet parsing more robust.

Thomas Strosslin, for reporting a major shortcoming in shntool's exit code
reporting (especially affecting conv mode), and for providing a patch to
address this issue.

Tom, for suggesting that hash mode use progress indicators, like other modes.

Paolo Saggese, for suggesting that shntool allow user-specified byte-shift
comparison buffer sizes in cmp mode, for those times when DAE is off by more
than the default of 3 seconds.

German Pulido, for reporting an issue in which self-extracting WavPack files
were not being properly detected by shntool.

Albin Larsson, for suggesting that fix mode should handle the case where just
a single file is specified (essentially postpad the file), which is especially
useful when using the -c option to check files for boundary issues.

Robert Rozee, for suggesting that shntool could read input filenames from a
file, instead of listing everything on the command line.

Mark, for reporting multiple issues with cat mode and providing fixes.

-------

Thanks also goes to the developers of the following software, from which I have
taken both ideas and code for shntool:

xmms - shntool's WAVE header parsing algorithm was based on the one in xmms's
       WAVE input plugin

proftpd - shntool's method for gluing modules together was adapted from the way
          proftpd handles it

sox - the WAVE_FORMAT_* defines and format_to_str() function were taken from the
      sox distribution

coreutils - the MD5 and natural filename sorting algorithms were lifted from the
            GNU coreutils distribution

v2strip - shntool's ID3v2 detection was based on the v2strip implementation

==================
Document revision:
==================

$Id: CREDITS,v 1.30 2009/03/30 06:31:13 jason Exp $

Five · #49 2020-02-16, 10:55 PM

shntool tutorial by Jason Jordan, 2004-05-05

part one of three

Code:

shntool 2.0.3 tutorial
----------------------

This is a fairly brief but hopefully useful document on how to use shntool and
its various modes. It is a work in progress, so take what it says with a grain
of salt. I will try to keep it current with each new release. However, even if
this document becomes dated, shntool's built-in help screens as well as its man
page (i.e. the README.txt for Windows folks) will be kept current, so if you
have any troubles you can consult those sources of information. The help
screens can be accessed from any mode by giving the '-h' command-line switch.

NOTE: For the purposes of this tutorial, all sample commands will be given in
their long form (e.g. 'shntool len' as opposed to 'shnlen'), since some
platforms do not support symbolic links, which allow one to use the short form.
Also, the '%' represents the command prompt, whatever platform you are on.
Most of you know this, but this is for those who don't, so that I don't get any
email saying "When I run '% shntool', it says 'command not found'!!!!" :^)

shntool's modes can generally be split into three categories - modes that simply
display information about given files, modes that create new files based on
input files, and modes that do something else that is not covered by the above
two categories.

Contents:

1. Modes that display information
1a. len mode
1b. info mode
1c. md5 mode
1d. cue mode
2. Modes that create files
2a. fix mode
2b. join mode
2c. split mode
2d. strip mode
2e. conv mode
2f. pad mode
3. Miscellaneous modes
3a. cat mode
3b. cmp mode
4. Custom format modules
4a. cust format

=================================
1. Modes that display information
=================================

Currently len, info, md5, and cue modes are the only modes that simply show
information about files. All of these modes read filenames from the command
line, or from standard input if none are given on the command line.

------------
1a. len mode
------------

len mode shows a one-line summary detailing many properties of a given file.
Below is sample output from len mode:

% shntool len *.shn
length expanded size cdr WAVE problems filename
18:39.49 197506892 --- -- ---xx gd72-08-27d2t01.shn
8:48.56 93270956 --- -- ---xx gd72-08-27d2t02.shn
4:58.46 52675436 --- -- ---xx gd72-08-27d2t03.shn
12:18.62 130329068 --- -- ---xx gd72-08-27d2t04.shn
5:32.39 58656572 --- -- ---xx gd72-08-27d2t05.shn
50:18.27 532438924 B (totals for 5 files, 0.5612 overall compression ratio)
%

NOTE: overall compression ratio is simply the total size of the actual files on
the disk divided by the total size of the WAVE data (i.e. the header,
data, and extra RIFF chunks) contained in the files. Thus, any data
appended or prepended to input files (such as ID3 tags, ID3v2 tags or seek
tables) will increase the overall compression ratio, even pushing it above
1.0000! While seemingly counterintuitive, this makes sense, since the
extra data only serves to reverse the effect of any compression done to a
given file.

Here are some files that show off many of the property/problem flags described
in the "Explanation of output columns" section below:

% shntool len < test.list
length expanded size cdr WAVE problems filename
0:00.543 6030 cxx -- ----- doh.wav
0:00.543 6030 cxx -- ----j doh-withjunk.wav
4:08.31 43820156 --- -- 3--xx test-ok.shn
4:08.31 43820156 --- -- 3---- test-ok.wav
0:19.535 215420 cxx he ----- test-he.wav
0:06.123 135876 cxx -e ----- test-e.wav
0:06.123 135049 cxx -- ---t- test-t.wav
3:40.40 38901578 -b- -e ---xx test-be.shn
10:01.65 106169336 --- h- ---xx test-h.shn
22:32.076 233209631 B (totals for 9 files, 0.6327 overall compression ratio)
%

You can specify an alternate totals unit with the -u command-line switch. For
example, running:

% shntool len -u mb *.shn

on the first set of files listed above will produce identical output, except for
the totals line which will be shown in terms of megabytes instead of bytes:

50:18.27 507.77 MB (totals for 5 files, 0.5612 overall compression ratio)

Explanation of output columns
-----------------------------

The 'length' column shows the length of the WAVE data in that file, in m:ss.nnn
format. If the WAVE data is CD-quality, then the length is shown in m:ss.ff
format, where ff is a number from 00 to 74 that best approximates the number of
frames (2352-byte blocks) remaining after m:ss. If all files given are
CD-quality, then the total length is displayed in m:ss.ff format; otherwise, the
total length will be displayed in m:ss.nnn format.

Note on rounding: If the WAVE data is CD-quality, then its length is rounded to
the nearest frame. Otherwise, it is rounded to the nearest
second.

The 'expanded size' column shows the total size of the WAVE header, WAVE data
and any other RIFF chunks appended to the file. Essentially this shows exactly
how large a file is (or will be when it is decompressed). NOTE: Do not rely on
this field for audio size! If you simply want to know how many bytes of audio
are in a file, run it through info mode, and look at the "data size" field in
its output.

The following three columns - cdr, WAVE and problems - attempt to show
properties and/or problems associated with the corresponding file. Each entry
under a particular column stands for a specific property/problem. In all three
columns, whenever that entry is applicable and checks out okay, a '-' will
appear in its place; and whenever that entry is not applicable or cannot be
determined, an 'x' will appear in its place. However, if a particular entry
does not check out okay, you will see a unique letter corresponding to what
went wrong. Read on for more information about what these letters mean.

The 'cdr' column shows properties of CD-quality WAVE data. There are three
entries under this column. The first entry will contain a 'c' if the WAVE data
is not CD-quality. The second entry will contain a 'b' if the data is
CD-quality, but not cut on a sector boundary. The third entry will contain an
's' if the data is CD-quality, but too short to be burned (i.e. 705600 bytes - 4
seconds worth of CD-quality WAVE data).

The 'WAVE' column shows properties of the WAVE data for any file. These properties
are not problems; they are just indicators of WAVE data that is not canonical.
There are two entries under this column. The first entry will contain an 'h' if
the WAVE header is not canonical (44 bytes). The second entry will contain an
'e' if the WAVE file contains extra RIFF chunks, other than the required 'fmt'
and 'data' chunks. Files that exhibit one or both of these properties can be
made canonical by stripping the unnecessary data via shntool's built-in strip
mode.

The 'problems' column shows problems with the WAVE header, WAVE data or the file
itself, for the given file. There are four entries under this column. The
first entry will contain a '3' if the file contains an ID3v2 tag. The second
entry will contain an 'a' if the audio data is not block-aligned, i.e. the data
size is not a multiple of the block align. The third entry will contain an 'i'
if the header size plus the reported data size is greater than the calculated
total size taken from the header (i.e. chunk size + 8). The fourth entry will
contain a 't' if the calculated total size is greater than the file's actual
size, and the file is not compressed (e.g. a .wav file). The fifth entry will
contain a 'j' if the calculated total size is less than the file's actual size,
and the file is not compressed. The last two entries are only verified for WAVE
data that is not compressed, since it would take far too long to verify this for
compressed WAVE data as well.

Summary of one-character abbreviations:

all columns:

'-' this particular entry is OK
'x' this particular entry is not applicable or cannot be determined

cdr column:

'c' data is not [C]D-quality
'b' CD-quality WAVE data is not cut on a sector [b]oundary
's' CD-quality WAVE data is too [s]hort to be burned

WAVE column:

'h' WAVE [h]eader is not canonical
'e' WAVE file contains [e]xtra chunks

problems column:

'3' file contains an ID[3]v2 tag
'a' audio data is not block-[a]ligned
'i' WAVE header is [i]nconsistent about data size and/or file size
't' WAVE file seems to be [t]runcated
'j' WAVE file seems to have [j]unk appended to it

-------------
1b. info mode
-------------

info mode shows a detailed, multi-line listing of the properties of a given
file. Below is sample output from info mode when run on just one file.

NOTE: for CD-quality files, the sector-misalignment is simply the remainder
when the data size is divided by 2352; i.e. it is the number of bytes
by which the audio data exceeds the previous sector boundary.

% shntool info kottke1992-07-04d1t17.shn
-------------------------------------------------------------------------------
file name: kottke1992-07-04d1t17.shn
handled by: shn format module
length: 4:37.45
WAVE format: 0x0001 (Microsoft PCM)
channels: 2
bits/sample: 16
samples/sec: 44100
average bytes/sec: 176400
rate (calculated): 176400
block align: 4
header size: 44 bytes
data size: 48969228 bytes
chunk size: 48969264 bytes
total size (chunk size + 8): 48969272 bytes
actual file size: 21108269
file is compressed: yes
compression ratio: 0.4311
CD-quality properties:
CD quality: yes
cut on sector boundary: no
sector misalignment: 588 bytes
long enough to be burned: yes
WAVE properties:
non-canonical header: no
extra RIFF chunks: no
Possible problems:
file contains ID3v2 tag: no
data chunk block-aligned: yes
inconsistent header: no
file probably truncated: unknown
junk appended to file: unknown
odd data size has pad byte: n/a
Extra shn-specific info:
seekable: no

NOTE: compression ratio is simply the total size of the actual file on the disk
divided by the total size of the WAVE data (i.e. the header, data, and
extra RIFF chunks) contained in the file. Thus, any data appended or
prepended to the file (such as ID3 tags, ID3v2 tags or seek tables) will
increase the compression ratio, even pushing it above 1.0000! While
seemingly counterintuitive, this makes sense, since the extra data only
serves to reverse the effect of any compression done to the file.

------------
1c. md5 mode
------------

md5 mode computes the MD5 fingerprint of the WAVE data contained within input
files. This can be used to catalog unique sources of audio, and to determine
whether files stored in one format are identical in terms of audio data. The
string "[shntool]" is added to the output to distinguish these MD5 sums from
normal MD5 sums. If you want to calculate the composite MD5 fingerprint from
a set of files, use the -c option. The composite MD5 sum can be useful for
fingerprinting a file set, or identifying file sets that contain the exact same
audio data, but different track breaks (e.g. file sets that have been "fixed",
with no padding added).

NOTE: The -c option is equivalent to the following commands:

a) % shntool cat -nh -np -nr <files> | md5sum

b) % shntool join -nopad <files>
% shntool md5 joined.wav

The advantage of the -c option over a) is that it can be uses on systems
that don't have md5sum installed, and the advantage over b) is that no
extra disk space is required for the joined file.

Here is the output for one source of a particular show:

% shntool md5 *.shn
b3b7d3f6c6b0ffc88e6588f4f279d97e [shntool] ph1993-08-20d1t01.shn
dc989e4aa15b31b8389814d7ac945c87 [shntool] ph1993-08-20d1t02.shn
e3e3276ce8c1d5aac3ba9c603d9a1810 [shntool] ph1993-08-20d1t03.shn
1cc17eaef4c086222bbb5974e61de72f [shntool] ph1993-08-20d1t04.shn
6a1b42c3d592b3004212dc6ac36649ea [shntool] ph1993-08-20d1t05.shn
0c177bcb31e882efee9bd5930cf9c2ec [shntool] ph1993-08-20d1t06.shn
0bf26039c8bb42c15518f0c4988dd01e [shntool] ph1993-08-20d1t07.shn
b82f32b6c727e465ba7a925a2bf0f7f7 [shntool] ph1993-08-20d1t08.shn
1164b3207df6916621808ff4ee2ac9b7 [shntool] ph1993-08-20d1t09.shn
32dc984bd441a4703a5b65902583ec45 [shntool] ph1993-08-20d2t01.shn
14f466e265499a56aacbfb7144057d37 [shntool] ph1993-08-20d2t02.shn
8a35ff394515baa062610172f125e376 [shntool] ph1993-08-20d2t03.shn
a23d9996e43df5107a802b3aba4a2830 [shntool] ph1993-08-20d2t04.shn
8a35eb14fcbb0dacbad1915a07746400 [shntool] ph1993-08-20d2t05.shn
1808c90d6728dd151eafd3d6135d1ee0 [shntool] ph1993-08-20d2t06.shn
afe8dd6c67afa59d2f31fb04dc6a78c1 [shntool] ph1993-08-20d2t07.shn
136f555973b5a92433522f0fccf05e7d [shntool] ph1993-08-20d3t01.shn
8cffae094165d8a5bffacd5198dd53a7 [shntool] ph1993-08-20d3t02.shn
08c9532a2c07750cb7ccb5cbe678da6b [shntool] ph1993-08-20d3t03.shn
a8c76355bd329d563b79d4ac75485314 [shntool] ph1993-08-20d3t04.shn
e2429980fd995cb19764b7768ff188e3 [shntool] ph1993-08-20d3t05.shn
%

Here is an example showing how the MD5 sum of WAVE data remains constant
even though the compression formats differ:

% shntool md5 example.*
e09f22c64d717ed89c6009b52fcfddd2 [shntool] example.aiff
e09f22c64d717ed89c6009b52fcfddd2 [shntool] example.ape
e09f22c64d717ed89c6009b52fcfddd2 [shntool] example.flac
e09f22c64d717ed89c6009b52fcfddd2 [shntool] example.ofr
e09f22c64d717ed89c6009b52fcfddd2 [shntool] example.pac
e09f22c64d717ed89c6009b52fcfddd2 [shntool] example.shn
e09f22c64d717ed89c6009b52fcfddd2 [shntool] example.wav
%

Here's one way to find the MD5 fingerprint of all your audio files:

% find /audio/dir | shntool md5 2>/dev/null

Here's an example showing the usefulness of the -c option. Notice how the
individual MD5 fingerprints change, while the composite MD5 fingerprint
remains constant (as long as no padding is added to the fixed files):

% shntool md5 *.flac
3ec1532ce893a8e845a3a1c5ff6db537 [shntool] gd1966-07-16d01t08.flac
3a5e83dec13f396be2f0d10b848f1f30 [shntool] gd1966-07-16d01t09.flac
% shntool md5 -c *.flac
09fdf2f9d7c55b007a5cc738a67662ee [shntool] composite
% shntool fix -o flac -nopad *.flac
shntool [fix]: warning: no shift direction specified - assuming backward shift
gd1966-07-16d01t08.flac --> gd1966-07-16d01t08-fixed.flac ... done.
gd1966-07-16d01t09.flac --> gd1966-07-16d01t09-fixed.flac ... done.
File 'gd1966-07-16d01t09-fixed.flac' was not padded, though it needs 420 bytes of padding.
% shntool md5 *fixed*.flac
d666d3a7ff07981210d57707e6de86be [shntool] gd1966-07-16d01t08-fixed.flac
1007bed4c0b891213e5b3e837d41c6a5 [shntool] gd1966-07-16d01t09-fixed.flac
% shntool md5 -c *fixed*.flac
09fdf2f9d7c55b007a5cc738a67662ee [shntool] composite

------------
1d. cue mode
------------

The purpose of cue mode is to generate a CUE sheet or a set of split points
from a set of files. You can use a CUE sheet to burn data joined from a set
of files, or to re-split the same joined data by feeding the CUE sheet to
split mode. Since CUE sheets are sector-aligned by design, cue mode also
allows you to create explicit byte-offset split points from a set of files.
That way, you can re-split the joined data in exactly the same places in which
it was originally split, whether the tracks were sector-aligned or not.

Here is an example showing a CUE sheet created from a set of files:

% shntool cue *.flac
shntool [cue]: warning: no output type specified - assuming CUE sheet
FILE "joined.wav" WAVE
TRACK 01 AUDIO
INDEX 01 0:00:00
TRACK 02 AUDIO
INDEX 01 1:30:07
TRACK 03 AUDIO
INDEX 01 2:57:43
TRACK 04 AUDIO
INDEX 01 9:25:44
TRACK 05 AUDIO
INDEX 01 17:23:58
TRACK 06 AUDIO
INDEX 01 27:47:63
TRACK 07 AUDIO
INDEX 01 37:05:16
TRACK 08 AUDIO
INDEX 01 40:53:63
%

If you want raw split points instead, use the '-s' option:

% shntool cue -s *.flac
15892464
31323936
99769488
184121616
294206976
392527632
432857376
%

Five · #50 2020-02-16, 10:57 PM

shntool tutorial by Jason Jordan, 2004-05-05

part two of three

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.

Five · #51 2020-02-16, 10:57 PM

shntool tutorial by Jason Jordan, 2004-05-05

part three of three

Code:

======================
3. Miscellaneous modes
======================

The following modes don't quite fit in the categories listed above.

------------
3a. cat mode
------------

The purpose of cat mode is to write (catenate) the WAVE header, WAVE data,
and/or extra RIFF chunks from one or more files to standard output.  This can be
useful for things like on-the-fly CD burning or streaming audio.  Typing:

% shntool cat filename

or

% echo "filename" | shntool cat

will write the WAVE header, WAVE data, and any extra RIFF chunks from the given
file to standard output.  If you want to suppress the WAVE header and extra RIFF
chunks (which, if not suppressed, can cause 'clicks' at the beginning and/or end
of tracks when piping output to a CD-burning program that expects raw WAVE
data), then give the '-nh' (no header) and '-nr' (no extra RIFF chunks)
switches:

% shntool cat -nh -nr filename

If you only need to output the WAVE header, then use the '-nd' (no data) and
'-nr' switches:

% shntool cat -nd -nr filename

The only use I can think of for this at the moment is for bug reporting.
Sometimes I only need to see WAVE headers to debug a problem, and this provides
a way for you to get them to me.  I hope you never have to use this option for
that reason, though.  :^)


------------
3b. cmp mode
------------

The purpose of cmp mode is to compare the WAVE data contained within two files.
This is useful if you want to verify the results CD-audio extraction against the
original files.  This can also be used to compare the WAVE data within two files
of different formats (e.g. file1.wav and file2.shn), for which other methods of
verification such as md5sum will not do.  Since this mode ignores WAVE headers
and extra RIFF chunks when making the comparison, it can also be used to compare
files that have been stripped (see strip mode above) to their unstripped
counterparts, which is another situation where md5sum would not be sufficient.

Before running the comparison, the WAVE headers are examined for differences.
If any value in the headers differ other than the reported data size or the
block align, then an error is reported and the files are not compared.
Otherwise, if the size of the WAVE data differs in the two files to be compared,
then a comparison is run only up to the size of the smaller of the two; and if
the block align values differ, then a warning is printed (since some CD-quality
WAVE files have headers that report a block align of 4 instead of 2), but the
comparison continues (since it seems that the block align is often ignored by
programs).

When run normally, cmp mode will either say the files are identical, or exit at
the first differing byte.  If you want to see all differing bytes (and their
values), use the -l option.  If any bytes differ, you will see a list of
offsets, similar to 'cmp -l' under UNIX.  In particular, offsets are 1-based,
meaning the first byte is offset 1, not 0.  The byte values of the differing
bytes in each file are also shown for reference.

Sometimes you might want to compare data in two files, one of which might
contain extra bytes at the beginning (such as a file ripped from a CD burned TAO
which might have an initial 2-second gap of silence, depending on the program
used to rip it).  In this case, you can use the -s option to have shntool
determine whether one of the files contains extra bytes at the beginning of the
WAVE data.  This option can also help identify a CD burner/CD reader combined
read/write offset.  Currently, only the first 529200 bytes (3 seconds of
CD-quality WAVE data) are searched for identicalness, but this should be more
than enough for most purposes.  If for some reason you believe that the files
are byte-shifted, but shntool does not think so, you can use the -f switch to
give shntool a "fuzz factor" that it will use.  This fuzz factor is simply a
positive integer that represents the maximum number of allowable byte mismatches
within the first 529200 bytes.  This allows you to check for differing bytes
between to files that (a) are byte-shifted and (b) contain at least one error
within the first 529200 bytes (an error that could have been cause by an
unreadable section of the CD, an unreliable CD reader, a bad hard drive/hard
drive cable, a network error, buggy hardware drivers, etc.).  The higher the
fuzz factor, the longer the -s option takes, so set it low at first (e.g. 8),
and increase it in small steps if needed.  Note that the -f option can only be
used with the -s option, since that's the only time the fuzz factor is used.

Here's an example comparison:

% shntool cmp test.wav test2.shn
comparing WAVE data in files 'test.wav' and 'test2.shn' ... 

contents of these files are identical.
%

Here's what you will see if the WAVE data sizes differ, but are identical up to
the WAVE data size of the smaller file:

% shntool cmp cmp1a.wav cmp1b.wav
shntool [cmp]: warning: size of data to be compared differs between these files -
                        WAVE data will only be compared up to the smaller size
comparing WAVE data in files 'cmp1a.wav' and 'cmp1b.wav' ... 

contents of these files are identical (up to the first 29332188 bytes of WAVE data).
%

Here's an example of what you might see if the WAVE data itself differs:

% shntool cmp test.wav test3.wav
comparing WAVE data in files 'test.wav' and 'test3.wav' ... 

WAVE data differs at byte offset 9847801.
%

Curious what the differences were in the above case?  Let's see:

% shntool cmp -l test.wav test3.wav
comparing WAVE data in files 'test.wav' and 'test3.wav' ... 

    offset   1   2
   ----------------
   9847801  13 157
  10619542 216  47

contents of these files differed as indicated above.
%

Now let's check a ripped file against its pre-burned couterpart:

% shntool cmp preburned.shn ripped.wav
shntool [cmp]: warning: size of data to be compared differs between these files -
                        WAVE data will only be compared up to the smaller size
comparing WAVE data in files 'preburned.shn' and 'ripped.wav' ... 

WAVE data differs at byte offset 1.
%

Oops, we should have used the -s option:

% shntool cmp -s preburned.shn ripped.wav
checking for byte-shift between input files...

file 'ripped.wav' seems to have:

  350448 extra bytes (87612 extra samples, or 149 extra sectors)

these extra bytes will be discarded before comparing the data.

preparing to do full comparison...

comparing aligned WAVE data in files 'preburned.shn' and 'ripped.wav' ... 

aligned contents of these files are identical.
%

Let's check two files that we think are identical, but one of which was ripped
from a sun-bleached, flaking, scratched CD:

% shntool cmp -s preburned2.shn ripped2.wav
checking for byte-shift between input files...

files 'preburned2.shn' and 'ripped2.wav' do not share identical data within the first 529200 bytes.
%

Hmm, I still think they are identical... let's use a fuzz factor to check:

% shntool cmp -s -f 8 preburned2.shn ripped2.wav
checking for byte-shift between input files...

with fuzz factor 8, file 'ripped2.wav' seems to have:

  350448 extra bytes (87612 extra samples, or 149 extra sectors)

these extra bytes will be discarded before comparing the data.

preparing to do full comparison...

shntool [cmp]: warning: size of data to be compared differs between these files -
                        WAVE data will only be compared up to the smaller size
comparing aligned WAVE data in files 'preburned2.shn' and 'ripped2.wav' ... 

WAVE data differs at byte offset 137.
%

Hmm, I wonder where else they differ:

% shntool cmp -s -f 8 -l preburned2.shn ripped2.wav
checking for byte-shift between input files...

with fuzz factor 8, file 'ripped2.wav' seems to have:

  350448 extra bytes (87612 extra samples, or 149 extra sectors)

these extra bytes will be discarded before comparing the data.

preparing to do full comparison...

shntool [cmp]: warning: size of data to be compared differs between these files -
                        WAVE data will only be compared up to the smaller size
comparing aligned WAVE data in files 'preburned2.shn' and 'ripped2.wav' ... 

    offset   1   2
   ----------------
       137 227 228
      1653 216 215
     56820  13 157

aligned contents of these files differed as indicated above.
%


========================
4. Custom format modules
========================

There is only one custom format module, 'cust'.  It is described below.

---------------
4a. cust format
---------------

The cust format provides the user with a means of specifying the precise
program and arguments shntool should use to encode output files.  This is
useful for overriding shntool's defaults for existing output formats, and
for enabling shntool to create files in a format that it does not yet
officially support.  The cust format has a simple format:

  { program argument_1 argument_2 ... argument_N }

This will create files with an extension of .custom by default.  If you wish
to provide your own extension (e.g. 'abc'), use this format:

  ext=abc { program argument_1 argument_2 ... argument_N }

NOTE:
-----
  At least one of the arguments must contain the string '%f', which is the
  placeholder for the output filename.  The cust format module will stick
  the output filename here, with the appropriate extension.

NOTE TO WINDOWS USERS:
----------------------
  Due to the way the Windows command prompt operates, you will need to put
  quotes around the curly braces, i.e.:  '{' program argument_1 ... '}'
  Also, if you use cust mode inside a batch file, you must use '%%f' instead
  of '%f'.


Here are two example uses for the cust output format.  The first shows how
you can use it to override an existing format module's default options, and
the second shows how you can use it to encode to a totally new format.

1.  Suppose you want to fix a set of files, and in the process create .shn's
    that are NOT seekable.  Here's one way to do it.  Note that although
    the output shows an extension of .custom, the files will really have the
    specified extension of .shn:

% shntool fix -noskip -o cust ext=shn { shorten -v2 - %f } *.shn
shntool [fix]: warning: no shift direction specified - assuming backward shift
gd80-10-11d1t01.shn --> gd80-10-11d1t01-fixed.custom ... done.
gd80-10-11d1t02.shn --> gd80-10-11d1t02-fixed.custom ... done.
gd80-10-11d1t03.shn --> gd80-10-11d1t03-fixed.custom ... done.
gd80-10-11d1t04.shn --> gd80-10-11d1t04-fixed.custom ... done.
gd80-10-11d1t05.shn --> gd80-10-11d1t05-fixed.custom ... done.
gd80-10-11d1t06.shn --> gd80-10-11d1t06-fixed.custom ... done.
gd80-10-11d1t07.shn --> gd80-10-11d1t07-fixed.custom ... done.
gd80-10-11d1t08.shn --> gd80-10-11d1t08-fixed.custom ... done.
gd80-10-11d1t09.shn --> gd80-10-11d1t09-fixed.custom ... done.
gd80-10-11d1t10.shn --> gd80-10-11d1t10-fixed.custom ... done.
No padding needed for 'gd80-10-11d1t10-fixed.custom'.
% shntool info *fixed.shn | grep seekable
  seekable:                   no
  seekable:                   no
  seekable:                   no
  seekable:                   no
  seekable:                   no
  seekable:                   no
  seekable:                   no
  seekable:                   no
  seekable:                   no
  seekable:                   no
%

An alternate way of specifying the .shn extension is as follows:

% shntool fix -noskip -o cust ext= { shorten -v2 - %fshn } *.shn


2.  Suppose you want to convert a set of files to a new format that shntool
    does not currently support.  Let's make one up named 'crunch'.  Assuming
    this fictitious format has a command-line program that will encode WAVE data
    read on standard input, all you have to do is figure out the proper
    arguments for doing so and plug it into the cust format module:

% shntool conv -o cust ext=crunch { wavcrunch -level 9 -input - -output new-%f } *.wav
converting 'test1.wav' to 'test1.custom' ... done.
converting 'test2.wav' to 'test2.custom' ... done.
converting 'test3.wav' to 'test3.custom' ... done.
%

Again, the files created above would have the specified extension of .crunch, not
the .custom extension shown.  Also, each file would be prefixed with the string
"new-", since that's what was specified to the encoder.  Thus, the three files
created in the above example would be named "new-test1.crunch", "new-test2.crunch"
and "new-test3.crunch".


==================
Document revision:
==================

$Id: TUTORIAL,v 1.77 2004/05/05 07:37:46 jason Exp $

Five · #52 2020-02-18, 02:33 AM

early shntool documentation only online for a few months, 2000-11-09

Quote:

Originally Posted by Jason Jordan

shntool

What is it?
What does it do?
Len mode
Fix mode
Where can I get it?
How do I compile the source?
Command-line switches
How do I run it?
Len mode examples
Fix mode examples
Known bugs
Future improvements
Credits
Contact information

What is it?

shntool is a multi-purpose .wav/.shn processing utility. File formats are abstracted from the functions that perform the real work in shntool. Thus, .shn files and .wav files are structurally identical from its perspective.

As far as its functionality, shntool currently has several uses. shntool can:

report size/length information about the WAVE data within .wav and/or .shn files
write corrected files for input files that weren't cut on sector boundaries (in this respect, it's sort of a rudimentary CDWave for unix, except it can read and write .shn's as well as .wav's)
write a concatenated .wav or .shn file from the given .wav and/or .shn files
print all WAVE information contained in the header of .wav and/or .shn files

shntool has native support for .wav files. If you want to also work with .shn files, you must have shorten somewhere in your default PATH.

shntool is currently beta software (though I run it with no problems). Keep this in mind! If you use shntool, be sure to double-check its results until you feel comfortable with it.

If you have a great idea for shntool, let me know! Or code it yourself - shntool is GPL'ed. ;-)

What does it do?

Depending upon the mode it is run in, shntool will perform certain actions. shntool currently has two modes, 'len' mode and 'fix' mode.

Note that any error messages are printed to stderr, so you can redirect them to /dev/null if you don't want to see them. (I suggest you don't do this while in fix mode, because error messages there are pretty important.)

Len mode

In len (length) mode, files are quickly scanned to determine their contents. Len mode takes the following arguments:

an optional argument from the following list (if none is given, the default unit is bytes):
"-kb" to specify that totals should be output in kilobytes
"-mb" to specify that totals should be output in megabytes
"-gb" to specify that totals should be output in gigabytes
an optional argument, "-debug", to specify that all of the following information be printed for each file given, instead of the standard output line (described below):
the file name
length, in mm:ss format
samples per second
number of channels
bits per sample
average bytes per second
rate (should equal average bytes per second)
block align
header size
data size
total size
chunk size
any errors associated with the file

If the file is a .wav file (not a .shn), then to aid in debugging 'hdr' errors, you will also see:

header size + data size
chunk size + 8
actual size

All three of the above should match.

finally, optional file names to process. If none are given, then file names are read from standard input.

If "-debug" is not specified, then for each valid file name given, shntool reports the following information:

the length of the WAVE data within the .wav or .shn, in minutes:seconds format
the exact size, in bytes, of the WAVE data within that .wav or .shn
One of the following status indicators:
the word "bound" if the WAVE data within that .wav or .shn is not cut on a sector boundary, or
the word "short" if the WAVE data within that .wav or .shn is too short to be burned, or
the word " hdr " if the WAVE header within that .wav contains incorrect information with respect to sizes (not applicable to .shn files), or
the character " - " (dash, or minus sign) otherwise
the file name of the .wav or .shn

After all files have been processed, it will report the total run length and disk space used and/or needed for the given files.

Fix mode

In fix mode, the given files are checked for .shn and/or .wav validity, and are processed only if (a) all files pass the check and (b) all files have identical headers (to prevent accidental mixing of different WAVE streams). Fix mode takes the following arguments:

a required argument, "-wav" or "-shn", which specifies .wav or .shn output, respectively
a required argument from the following list:
"-b" to specify that track breaks be moved backward to the previous multiple of 2352 bytes, where necessary, or
"-f" to specify that track breaks be moved forward to the next multiple of 2352 bytes, where necessary, or
"-j" to specify that all WAVE data from the given files be joined together in one large output file (useful if you want to split the tracks with a more advanced .wav editor)
an optional argument "-d", which indicates that the next argument is the name of an alternate output directory
an optional argument "-pad" to force padding of the last file written in fix mode, if necessary
an optional argument "-order" to edit the order that your files will be processed (see the important note below)
finally, at least two filenames to process.

While running in fix mode, shntool displays which file it is currently processing. Output file names will be in the following format:

prefix-fixed.ext (for forward- and backward-shifted files created with "-f" or "-b")
joined.ext (for joined files created with "-j")

where 'prefix' is the basename of the input filename, and '.ext' is either '.shn' or '.wav', depending on what you specify. For example, assuming that the '-wav' command-line switch was given, 'th79-08-08d1t03.shn' would become 'th79-08-08d1t03-fixed.wav'.

If you use fix mode, make sure to listen to the resulting files to ensure that they came out alright. There is always the possibility of a bug lurking in the WAVE-splitting code.

IMPORTANT NOTE!

Because some shows contain files with non-etree-standardized names, simply running (for example) 'shntool -fix -shn -b *.shn' on those .shn's will produce unexpected (i.e. wrong) results, because of the wildcard expansion. That's why I've included an optional switch, "-order", which allows you to edit the order that the files will be processed. Typing (for example) 'shntool -fix -shn -b -order *.shn' will bring up this editor. Below is a chart showing an example of how non-etree-standardized file names can screw up the file order:

File order from wildcard expansion - Desired file order

track1.shn -- track1.shn
track10.shn - track2.shn
track11.shn - track3.shn
track12.shn - track4.shn
track13.shn - track5.shn
track2.shn -- track6.shn
track3.shn -- track7.shn
track4.shn -- track8.shn
track5.shn -- track9.shn
track6.shn -- track10.shn
track7.shn -- track11.shn
track8.shn -- track12.shn
track9.shn -- track13.shn

Where can I get it?

Right here. To see if you are using the most current version, type 'shntool -v'.

version 0.95, released 2000-10-19
+ Available as C source code (56711 bytes)
+ Now available for DOS/Windows: shntool.zip (316969 bytes) - thanks Caleb Epstein!
NOTE: Please consult the README file included in this zip file for installation instructions.
+ fixed bug where chunk size wasn't being updated for files that were altered in fix mode
+ added code to help determine whether shorten is in the default path
+ WAVE data for headers in .wav (not .shn) files are now verified
+ file names created in fix mode are now based on input filenames when -f or -b are given

version 0.94, released 2000-08-24
+ Available as C source code (53189 bytes)
+ added new fix mode switch "-pad" to force padding of the last file written with zeroed bytes up to the next multiple of the sector size, if necessary

version 0.93, released 2000-07-06
+ Available as C source code (51151 bytes)
+ I partially broke file reading from stdin in len mode in 0.92 - fixed.
+ did several other minor cleanups/corrections that did not affect the core functionality of shntool

version 0.92, released 2000-07-04
+ Available as C source code (49633 bytes)
+ added setlinebuf() support for architectures that don't have it (see the compiling section for more info)
+ added description of the len mode "-debug" flag to its help menu

version 0.91, released 2000-07-04
+ Available as C source code (49201 bytes)
+ WAVE headers are now processed correctly (this was the bug reported in version 0.9)
+ added "-debug" switch for len mode
+ fixed segfaults with headers > 64 bytes

version 0.9, released 2000-07-03
+ Available as C source code (45179 bytes)
+ Initial release

How do I compile the source?

Simple:

% gcc -Wall shntool.c -o shntool
%

NOTE: If you see the following error trying to compile shntool as above, try using the "-D_SETLINEBUF_HACK" compiler switch:

% gcc -Wall shntool.c -o shntool
shntool.c: In function `start_child':
shntool.c:311: warning: implicit declaration of function `setlinebuf'
% gcc -Wall -D_SETLINEBUF_HACK shntool.c -o shntool
%

Now stick 'shntool' somewhere in your PATH.

For ease of use, shntool recognizes when it is run as 'shnlen' and 'fixwav'. This way, by creating symbolic links to shntool with these names, you can avoid having to remember to specify which mode you want to run shntool in. Here's how to do this:

% cd /directory/where/shntool/is/installed
% ln -s shntool shnlen
% ln -s shntool fixwav
%

Thus, running 'shnlen' is equivalent to running 'shntool -len', and running 'fixwav' is equivalent to running 'shntool -fix'.

NOTE: If you previously installed the older program 'shnlen', make sure that you remove it before installing shntool. You can find out your shnlen version by typing 'shnlen -v'. If it's 0.5 or less, you need to remove the old shnlen executable.

The source is known to compile cleanly on the following platforms (given by 'uname -srm'):

Linux 2.2.x i686
Linux 2.2.x alpha
Linux 2.0.x i686
Linux 2.0.34 mips (Cobalt Qube)
SunOS 5.7 sun4u
SunOS 5.5.1 sun4u
SunOS 4.1.4 sun4c
FreeBSD 3.4-RELEASE i386
IRIX64 6.5 IP27
IRIX 6.5 IP22
HP-UX B.10.20 9000/735
add your platform here

Thanks to Steve B. for providing several of these entries.

If it does not compile on some other platform, but you successfully port it to that platform, please let me know!

Command-line switches

To see what command-line switches are supported, simply type 'shntool -h'.

% shntool -h
usage: shntool [ -len | -fix ] ...

For help with the -len switch, type 'shntool -len -h'.

For help with the -fix switch, type 'shntool -fix -h'.

%

How do I run it?

Here are some sample uses. How you use it is entirely up to you.

Len mode examples

Here's a file not cut properly on a sector boundary:

% shntool -len disc1/lc85-07-06d1t10.shn
4:45 50398704 bound disc1/lc85-07-06d1t10.shn
4:45 50398704 B (total for 1 file)
%

See exactly what information is contained within a troublesome file:

% shntool -len -debug lc85-07-06d1t10.shn
filename: lc85-07-06d1t10.shn
samples/sec: 44100
channels: 2
bits/sample: 16
avg. bytes/sec: 176400
rate: 176400
block align: 4
header size: 44
data size: 50398660
total size: 50398704
length: 4:45
errors: not cut on sector boundary
---------------------------------------------------------------
%

Get statistics for one disc of a show, and display totals in terms of megabytes:

% shntool -len -mb *.wav *.shn
29:12 309097532 gd78-10-22d1t1.shn
6:15 66288812 gd78-10-22d1t2.shn
4:33 48277196 gd78-10-22d1t3.wav
6:07 64891724 gd78-10-22d1t4.shn
9:49 104021948 gd78-10-22d1t5.wav
6:29 68749004 gd78-10-22d1t6.wav
10:29 111049724 gd78-10-22d1t7.shn
72:59 736.60 MB (totals for 7 files)
%

Find out how many gigabytes of WAVE data you have sitting within the .wav's and .shn's on your hard drive(s):

% find / -iname \*.shn -o -iname \*.wav | shntool -len -gb | tail -1
4966:56 48.96 GB (totals for 773 files)
%

Fix mode examples

Fix a disc of .shn's, where some files are not cut on sector boundaries, and write our fixed files as .shn's (note that the last file in a disc might still not be cut on a sector boundary, unless you specify the '-pad' option like I do below). I show the results of 'shntool -len' on these files, before and after fixing, for comparison:

% shntool -len ak98-08-21/disc1/*.shn
3:23 35911420 bound ak98-08-21/disc1/ak98-08-21t101.shn
4:23 46550828 - ak98-08-21/disc1/ak98-08-21t102.shn
3:57 41844476 - ak98-08-21/disc1/ak98-08-21t103.shn
4:27 47261132 - ak98-08-21/disc1/ak98-08-21t104.shn
4:16 45299560 bound ak98-08-21/disc1/ak98-08-21t105.shn
3:05 32803388 - ak98-08-21/disc1/ak98-08-21t106.shn
3:41 39113804 - ak98-08-21/disc1/ak98-08-21t107.shn
4:50 51193676 - ak98-08-21/disc1/ak98-08-21t108.shn
5:39 59804348 - ak98-08-21/disc1/ak98-08-21t109.shn
3:40 38979740 - ak98-08-21/disc1/ak98-08-21t110.shn
5:09 54547624 bound ak98-08-21/disc1/ak98-08-21t111.shn
5:00 53025872 bound ak98-08-21/disc1/ak98-08-21t112.shn
3:32 37455644 - ak98-08-21/disc1/ak98-08-21t113.shn
3:15 34503884 - ak98-08-21/disc1/ak98-08-21t114.shn
4:36 48780524 - ak98-08-21/disc1/ak98-08-21t115.shn
4:32 48110204 - ak98-08-21/disc1/ak98-08-21t116.shn
3:05 32681084 - ak98-08-21/disc1/ak98-08-21t117.shn
70:39 747867208 B (totals for 17 files)
% shntool -fix -shn -d /mnt/fixed -b -pad ak98-08-21/disc1/*.shn
ak98-08-21/disc1/ak98-08-21t101.shn --> /mnt/fixed/ak98-08-21t101-fixed.shn ... done.
ak98-08-21/disc1/ak98-08-21t102.shn --> /mnt/fixed/ak98-08-21t102-fixed.shn ... done.
ak98-08-21/disc1/ak98-08-21t103.shn --> /mnt/fixed/ak98-08-21t103-fixed.shn ... done.
ak98-08-21/disc1/ak98-08-21t104.shn --> /mnt/fixed/ak98-08-21t104-fixed.shn ... done.
ak98-08-21/disc1/ak98-08-21t105.shn --> /mnt/fixed/ak98-08-21t105-fixed.shn ... done.
ak98-08-21/disc1/ak98-08-21t106.shn --> /mnt/fixed/ak98-08-21t106-fixed.shn ... done.
ak98-08-21/disc1/ak98-08-21t107.shn --> /mnt/fixed/ak98-08-21t107-fixed.shn ... done.
ak98-08-21/disc1/ak98-08-21t108.shn --> /mnt/fixed/ak98-08-21t108-fixed.shn ... done.
ak98-08-21/disc1/ak98-08-21t109.shn --> /mnt/fixed/ak98-08-21t109-fixed.shn ... done.
ak98-08-21/disc1/ak98-08-21t110.shn --> /mnt/fixed/ak98-08-21t110-fixed.shn ... done.
ak98-08-21/disc1/ak98-08-21t111.shn --> /mnt/fixed/ak98-08-21t111-fixed.shn ... done.
ak98-08-21/disc1/ak98-08-21t112.shn --> /mnt/fixed/ak98-08-21t112-fixed.shn ... done.
ak98-08-21/disc1/ak98-08-21t113.shn --> /mnt/fixed/ak98-08-21t113-fixed.shn ... done.
ak98-08-21/disc1/ak98-08-21t114.shn --> /mnt/fixed/ak98-08-21t114-fixed.shn ... done.
ak98-08-21/disc1/ak98-08-21t115.shn --> /mnt/fixed/ak98-08-21t115-fixed.shn ... done.
ak98-08-21/disc1/ak98-08-21t116.shn --> /mnt/fixed/ak98-08-21t116-fixed.shn ... done.
ak98-08-21/disc1/ak98-08-21t117.shn --> /mnt/fixed/ak98-08-21t117-fixed.shn ... done. Padded this file with 1332 zero bytes.
% shntool -len -pad /mnt/fixed/*fixed.shn
3:23 35910380 - /mnt/fixed/ak98-08-21t101-fixed.shn
4:23 46550828 - /mnt/fixed/ak98-08-21t102-fixed.shn
3:57 41844476 - /mnt/fixed/ak98-08-21t103-fixed.shn
4:27 47261132 - /mnt/fixed/ak98-08-21t104-fixed.shn
4:16 45299564 - /mnt/fixed/ak98-08-21t105-fixed.shn
3:05 32803388 - /mnt/fixed/ak98-08-21t106-fixed.shn
3:41 39113804 - /mnt/fixed/ak98-08-21t107-fixed.shn
4:50 51193676 - /mnt/fixed/ak98-08-21t108-fixed.shn
5:39 59804348 - /mnt/fixed/ak98-08-21t109-fixed.shn
3:40 38979740 - /mnt/fixed/ak98-08-21t110-fixed.shn
5:09 54547628 - /mnt/fixed/ak98-08-21t111-fixed.shn
5:00 53025884 - /mnt/fixed/ak98-08-21t112-fixed.shn
3:32 37455644 - /mnt/fixed/ak98-08-21t113-fixed.shn
3:15 34503884 - /mnt/fixed/ak98-08-21t114-fixed.shn
4:36 48780524 - /mnt/fixed/ak98-08-21t115-fixed.shn
4:32 48110204 - /mnt/fixed/ak98-08-21t116-fixed.shn
3:05 32683436 - /mnt/fixed/ak98-08-21t117-fixed.shn
70:39 747868540 B (totals for 17 files)
%

Create one large .wav file from a disc's worth of .shn's, without padding it. Again, I show the results of 'shntool -len' on the joined file for comparison. Note that the joined files size will be smaller than the sum of the split files - this is due to the header lengths of the split files being counted in the total file size.

% shntool -fix -wav -j ak*.shn
Adding contents of ak98-08-21t101.shn to joined.wav ... done.
Adding contents of ak98-08-21t102.shn to joined.wav ... done.
Adding contents of ak98-08-21t103.shn to joined.wav ... done.
Adding contents of ak98-08-21t104.shn to joined.wav ... done.
Adding contents of ak98-08-21t105.shn to joined.wav ... done.
Adding contents of ak98-08-21t106.shn to joined.wav ... done.
Adding contents of ak98-08-21t107.shn to joined.wav ... done.
Adding contents of ak98-08-21t108.shn to joined.wav ... done.
Adding contents of ak98-08-21t109.shn to joined.wav ... done.
Adding contents of ak98-08-21t110.shn to joined.wav ... done.
Adding contents of ak98-08-21t111.shn to joined.wav ... done.
Adding contents of ak98-08-21t112.shn to joined.wav ... done.
Adding contents of ak98-08-21t113.shn to joined.wav ... done.
Adding contents of ak98-08-21t114.shn to joined.wav ... done.
Adding contents of ak98-08-21t115.shn to joined.wav ... done.
Adding contents of ak98-08-21t116.shn to joined.wav ... done.
Adding contents of ak98-08-21t117.shn to joined.wav ... done.
% shntool -len joined.wav
70:39 747866504 bound joined.wav
70:39 747866504 B (total for 1 file)
%

Known bugs

shntool's WAVE header parsing algorithm is not comprehensive - it only recognizes canonical WAVE headers and certain variations of the canonical format. Multiple RIFF chunks and/or other chunk types may cause the file to be declared "not a .shn or a .wav file." If you run into this problem, please let me know, and try to provide a way for me to get a hold of the offending file(s) so I can improve shntool. (Thanks to Jeff Kempka for reporting this bug)

Future Improvements

generalize the WAVE header parsing algorithm to support a wider range of headers
possibly add an option to write canonical WAVE headers in fix mode
possibly make shntool track-splitting more robust, so that it can split tracks according to user input, instead of just correcting the splits by jumping to the next (or previous) sector boundary
when in fix mode, have shntool check whether any changes would be made before processing files (you can do this manually by running shntool in len mode on the files to be processed)

I'm open to suggestions, so let me know if you have an idea for an improvement.

Credits

Special thanks goes out to Tim [tmo], whose ideas prompted the creation of this program's predecessor (shnlen), and whose diligent testing helped iron out the bugs in that program.

Thanks also goes out to Herschel Gelman, who had the great suggestion that shnlen could check to see whether the .wav files inside the .shn's were properly cut on sector boundaries.

Both of these ideas/functionalities were carried over into shntool.

Who do I contact if I have any questions/comments/suggestions/patches/bugs/flames?

Send it all to jasonxxxx.xxxxxxxx.xxx.

Five · #53 2020-02-18, 07:10 PM

Peter King's SHN 2k Batch Files ... The functionality of this software is most impressive and useful yet never carried forward into the flac era. it was linked for many years from etree.org top software links.

Peter King's SHN 2k Batch Files v0.9 beta7 · 7/16/02 is the final known revision. if anybody has a copy of this, please pm me, I was unfortunately only able to find Peter King's SHN 2k Batch Files v0.80 · 12/14/01 (shown below in full)

from the SHN2K homepage, only online from 2002-2003

Quote:

Originally Posted by Peter King

SHN2k -- the shorten compression assistant for Windows

Introduction

Today's tools for creating .shn files leave a lot to be desired the way content is organized -- noname.md5, anyone? -- and it occurred to me that a Better Way was within our grasp. Enter SHN2k, a batch file for Windows that creates a burn-ready folder of .shn files from your .wav source files. -- a .shn folder in complete compliance with the etree standard, available at your fingertips any time via the Start>Run panel.

SHN2k was born when I noticed there was no existing command-line tool for Windows 2000 in the etree archive. I began by duplicating the functionality of the existing 'compress.bat' code for Win98, but that only got my mind wandering about further things that could be done with the script! Around the same time, I had some sketchy content come my way in a few e-trades: files with inconsistent names, folders mixed with .shn and .mkw files (none of which matched the included 'noname.md5'), and the like. Why not create a tool that makes this sort of thing impossible?

Why not create a tool that does it all -- the right way?

What It Does

Best, I think, to say it with pictures!
These are your .wav files, ready for encoding... Start > Run > SHN2k project_name -- it's that easy! SHN2k creates .shn files, an .md5 file, encode notes, wrapped up in a .shnf (shorten folder) -- all named consistently.

[image missing] [image missing] [image missing]

SHN2k creates a folder completely ready to burn or to send to the FTP server of your choice. it also automatically creates a 'VERIFY' script for anyone who might be receiving these .shn files from you. Just double click on the included VERIFY script and it checks the validity of the .shn files and, if they pass the inspection, expands them.

If you'd like to see the encode_notes file or VERIFY_ script from the above example, click on their names. [these two links reproduced in full below]

How Do I Use It?

Before using SHN2k the first time, you've got to edit the script to reflect your specific PC system, namely where your .wav files are stored and where you'd like to resulting .shn content to go. To do this, simply open the script in Notepad and follow along -- the few lines that require your intervention are very clearly marked. You'll also see fields for your name and the equipment you regularly use to create your .shn files, which is used to create the 'encode_nodes' file. You only need to do this once -- and once you're ready, save the SHN2k script in your windows system directory:

windows 95/98/ME users save it to c:\windows\command
windows 2000/XP users save it to c:\winnt\system32
(In the SHN2k.zip file there are also handy shortcuts to these paths to make installation very simple.)

You also *must* have shortn32.exe and md5sum.exe installed in the same location. Please download them here. if you don't have them already. (mkwACT users *will* need to install these two additional files.)

Now that you've done that, the fun can begin!

To use SHN2k, all you need is a folder of .wav files that you'd like to convert to .shn. It is probably the best idea to name your source files as in the example above, namely

t01.wav
t02.wav
etc.

( I've configured EAC on my system to output tracks named in this fashion when I extract, or when I'm mastering a new source, I use 'Extract Regions' in SoundForge 4.5. If you'd like more info on how I get my source .wav files named this way, email me.)

Once you've got files ready to encode, it really is as easy as calling 'Start > Run > SHN2k' and providing it with the name of your .wav project, date and name of band, what have you.

At the end of the process, it will automatically open the resulting .shnf folder so you can further edit the 'encode notes' file -- add a setlist, venue details, etc., run the VERIFY script if you'd like to check the validity of the files you've just created, etc.

Downloads

SHN2k is completely free for non-commercial use. I cannot be held responsible for any damage or unpredictable results that befall your system as a result of using this script. But, having said that, it's just a formality. I've been using SHN2k exclusively to create my .shn material for the last three months. It works. :-)

SHN2k.zip download

Support Notes

As the name somewhat implies, SHN2k was developed originally and optimized for Windows 2000 since there was no existing command-line solution. Windows 9x functionality was an afterthought, and, while it works, certainly things aren't as silky as in Win2k.

Windows 98 users will have better results if, instead of calling SHN2k from Start > Run, they open a DOS session first. (Start > Run > command) Then, once the DOS box is open, run SHN2k.

If you've installed Windows in a non-standard location -- anything other than c:\windows or c:\winnt -- you're going to have to manually modify the code of SHN2k. If you need to do this, email me and I'll give you some pointers.

:: TODO for v1.00 --
:: chomp on one file at a time
:: resolve wav_md5 naming problem
:: menu driven
:: turbo mode !!!
:: investigate 'out of environment space' error in win98 w / start-run method LEADS TO VERSION # not working
:: works when memory is allocated to it explicitly, but not by default. wtf?!!?
:: accept argument after project_name to replace local .wav location (maybe)
:: if temp_dir already exists, make new path (in the event of multiple encode sessions)

:: *** if you direct output to a subfolder, at md5 creation there's a 'cannot find path specified'
:: 'starting compression' just as the thing is finishing???
:: *** if a file is in use -- output an error message when trying to move to temp directory
:: *** make everything read-write before processing
:: rename folder with .shnf extension depending on name???
:: PREP mode -- chops name of files in current folder up to t0x.wav (DARING!!!!!)
:: VERIFY script -- instead of 'confirming shn.md5' why not give specific name to the md5 being verified
:: VERIFY script doesn't work when content has lived on a CD-rom (read/write issues i suspect)

:: RECENTLY FINISHED:
:: VERIFY_.bat for win9x
:: remove .shn extension before extracting
:: extract mode
:: VERIFY script needs version number
:: 'processing PROJECT_NAME...'
:: VERIFY only extracts files starting with name same as its own - line 343
:: add only relevant files to the .md5 file
:: VERIFY pop open relevant window
:: win98 time/date stamping -- done, but why phantom character??
:: BLANK VARIABLE = usage notes
:: -edit mode brings up script into notepad??
:: create warning file in temp folder about premature ejections

encode_notes.txt

Code:

dbyrne_05-24-01_fm 
 
encoded by pwking	 (sleepypedro_at_yahoo.com) 
Wed 01/23/2002 @ 6:02pm 
 
audio extraction:  Plextor PX-W1610A ~ EAC (secure mode) ~ shn2k 
 
i rip, therefore i am! 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 
created by shn2k (v.0.9 beta5) 
the shorten compression assistant for windows 2000 + beyond 
written by peter w. king (sleepypedro_at_yahoo.com) 
(c)2002 crabcollective productions

VERIFY_ script

Code:

@echo off 
cls 
echo ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 
echo VERIFY_dbyrne_05-24-01_fm.bat 
echo created by shn2k (v.0.9 beta5) 
echo the shorten compression assistant for windows 2000 + beyond 
echo written by peter w. king (sleepypedro_at_yahoo.com) 
echo (c)2002 crabcollective productions 
echo ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 
echo verifying shn.md5 checksum 
echo. 
md5sum -c dbyrne_05-24-01_fm_shn.md5 
echo. 
if errorlevel=1 goto NOT_ROCKING 
if errorlevel=0 goto FULLY_ROCKING 
 
:NOT_ROCKING 
echo Please try re-downloading the track(s) in question.  Your copy doesn't match.  
goto end 
 
:FULLY_ROCKING 
if "C:\WINNT"=="C:\WINNT" goto NEXT_SECTION 
echo. 
lfnfor on 
:NEXT_SECTION 
echo shorten files validated -- 
echo i'll extract them for you now! 
echo. 
:FILE_RENAMER 
mkdir temp_dir 
FOR %%f in (dbyrne_05-24-01_fm*.shn) DO move "%%f" "temp_dir\%%f" 
cd temp_dir 
FOR %%f in (*.shn) DO rename *.* *. 
FOR %%f in (*) DO shortn32 -x %%f ..\%%f.wav 
FOR %%f in (*) DO rename * *.shn 
FOR %%f in (*.shn) DO move "%%f" "..\%%f" 
cd ..  
if "C:\WINNT"=="C:\WINNT" rmdir /Q temp_dir 
if "C:\WINNT"=="C:\WINDOWS" rmdir temp_dir 
explorer . 
:end

readme.txt

Code:

::**************************************************************
::*  SHN2K v0.80
::*  the shorten compression assistant for Windows 2000 & beyond
::*  written by peter w. king ([email protected])
::*  12-14-2001
::**************************************************************

Hi there!  Welcome to shn2k!  This script was written to facilitate the creation
of shorten files and their corresponding .md5 checksums that automagically conform
to the naming convention of your choice -- no more files named Track01.shn, Track02.shn
and the god-awful 'noname.md5'!  Try it, I think you'll like it!

Please edit the variables in the shn2k.bat file so that they match your exact setup, then save the file.

for win2000 / nt4 / XP(?) :  save it in the \system32 folder of your \winnt directory (probably c:\winnt\system32)
for win98:  save it in the \command folder of your \windows directory (probably c:\windows\command)

after that, using the script is as easy as

Start >
Run >
shn2k disk_name

it is assumed you've already got shortn32.exe and md5sum.exe installed correctly.  if not, download these small programs from www.etree.org and install them in the same folder where you've installed this script.

please email me with comments/questions/suggestions/etc.

::  TODO for v1.00
::  windows9x date/time stamping
::  return to original DOS directory?
::  menu driven
::  turbo mode !!!
::  extract mode
::  autogenerate confirmation.bat script that both confirms and extracts for recipients

Code:

::**************************************************************
::*  SHN2K v0.80
::*  the shorten compression assistant for Windows 2000 & beyond
::*  written by peter w. king ([email protected])
::*  12-14-2001
::**************************************************************
@echo off
goto variable_declaration

Hi there!  Welcome to shn2k!  This script was written to facilitate the creation
of shorten files and their corresponding .md5 checksums that automagically conform
to the naming convention of your choice -- no more files named Track01.shn, Track02.shn
and the god-awful 'noname.md5'!  Try it, I think you'll like it!

Please edit the variables in the section below these notes
so that they match your exact setup, then save the file.

for win2000 / nt4 / XP(?) :  save it in the \system32 folder of your \winnt directory (probably c:\winnt\system32)
for win98:  save it in the \command folder of your \windows directory (probably c:\windows\command)

after that, using the script is as easy as

Start >
Run >
shn2k disk_name

it is assumed you've already got shortn32.exe and md5sum.exe installed correctly.  if not, download these small programs from www.etree.org and install them in the same folder where you've installed this script.

see KNOWN ISSUES at the end for further notes
please email me with comments/questions/suggestions/etc.

::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
:variable_declaration
:: WHERE ARE YOUR WAV FILES STORED, d00d?
REM for example, if c:\wavs, set the variables as follows:
set wav_drive=c
set wav_path=wavs

REM the wav_path can also be a full pathname, e.g. 'data\wavs\doo-wop\60s'

:: WHERE SHALL I STORE YOUR SHN FILES, d00d?
set shn_drive=c
set shn_path=shn

:: USER SPECIFIC INFO
set your_name=dirk diggler
set your_email=dirk@feel_my_heat.org
set your_gear=some cd-rom ~ EAC ~ shn2k
REM you can't use the > mark, which is why i'm using the ~ above
set adjustable_slogan=i rip, therefore i am!

set temp_dir=shn2k
REM this folder will be deleted as soon as work is done.

REM ok, that's it!  now save the file and you're ready to go.
goto greenlight

:opening_credits
*  PREREQUISITES:
*  shortn32 & md5sum installed somewhere in your %PATH (eg. c:\winnt\system32 or c:\windows\command)
*
*  usage:
*  modify operating variables
*  open DOS shell (start > run > 'shn2k cd_name'  (without ' marks, and no spaces in 'cd_name')
*
**********************************************************

:highly_anomalous
REM echo %WINDIR%
if "%WINDIR%"=="C:\WINNT" echo you are using windows NT or 2000
if NOT "%WINDIR%"=="C:\WINDOWS" echo you are using windows 9x
goto end

::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
:  EVERYTHING BELOW IS PRODUCTION CODE.  DO NOT MODIFY.  THANKS.
::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::

::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
:wav_directory_is_bad
echo.
echo TROUBLE WITH YOUR CHOSEN WAV_DIRECTORY --
echo %wav_drive%:\%wav_path% doesn't exist; the program will end.
echo.
echo please edit the shn2k.bat file and modify the 'wav_path' variable
goto end

::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
:shn_directory_is_bad
if NOT exist %shn_path% mkdir %shn_drive%:\%shn_path%
echo.
echo your chosen shn_path, %shn_drive%:\%shn_path%,
echo did not exist so I created it for you.
echo.
goto checkup_pt2

::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
:shn32_no_esta_aqui
echo.
echo SHORTN32.EXE DOESN'T SEEM TO EXIST --
echo please install it correctly and try shn2k again; the program will now end.
echo.
goto end

::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
:greenlight
cls
echo **********************************************************************
echo *                                                                    *
echo *  SHN2K -- the shn compression assistant for Windows 2000 + beyond  *
echo *                                                                    *
echo *          written by peter w king ([email protected])           * 
echo *                                                                    *
echo **********************************************************************
echo.

::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
:checkup
REM if "%WINDIR%"=="C:\WINDOWS" if NOT exist %wav_drive%:\%wav_path% goto wav_directory_is_bad
REM if "%WINDIR%"=="C:\WINDOWS" if NOT exist %shn_drive%:\%shn_path% goto shn_directory_is_bad

REM why do these win9x lines work as you'd expect?

if "%WINDIR%"=="C:\WINNT" if NOT exist %wav_drive%:\%wav_path% goto wav_directory_is_bad
if "%WINDIR%"=="C:\WINNT" if NOT exist %shn_drive%:\%shn_path% goto shn_directory_is_bad

::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
:checkup_pt2
shortn32 -h > nul
if errorlevel=1 goto shn32_no_esta_aqui
if "%WINDIR%"=="C:\WINNT" goto opening_statement

::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
:special_for_w9x_users
lfnfor on

::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
:opening_statement

::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
:setup

%wav_drive%:
cd \
cd %wav_path%

mkdir %temp_dir%
FOR %%f in (*.wav) DO move "%%f" "%wav_drive%:\%wav_path%\%temp_dir%\%%f" > nul
REM echo just moved files to temp_dir
cd %temp_dir%
mkdir %shn_drive%:\%shn_path%\%1.shnf

::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
:wav_md5_&_shn_prep
echo preparing wav_md5 checksum
FOR %%f in (*.wav) DO md5sum "%%f" >> "%shn_drive%:\%shn_path%\%1.shnf\%1_wav.md5"
FOR %%f in (*.wav) DO rename *.* *.

::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
:shn_conversion
if "%WINDIR%"=="C:\WINNT" FOR %%f in (*) DO echo encoding track %%f.wav & shortn32 "%%f" "%shn_drive%:\%shn_path%\%1.shnf\%1_%%f.shn" > nul
if "%WINDIR%"=="C:\WINNT" goto file_cleanup
REM win98 wouldn't work like it should.  will be fixed for v1.
echo starting compression
FOR %%f in (*) DO shortn32 "%%f" "%shn_drive%:\%shn_path%\%1.shnf\%1_%%f.shn" > nul
echo compression complete

::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
:file_cleanup
FOR %%f in (*.) DO rename * *.wav
FOR %%f in (*.wav) DO move "%%f" "%wav_drive%:\%wav_path%\%%f" > nul
cd ..
if "%WINDIR%"=="C:\WINNT" rmdir /Q %temp_dir%
if "%WINDIR%"=="C:\WINDOWS" rmdir %temp_dir%
REM wow, why does microsoft break basic functionality between releases???

::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
:shn_md5_creation
cd %shn_drive%:\%shn_path%\%1.shnf
echo preparing shn_md5 checksum
FOR %%f in (*.shn) DO md5sum "%%f" >> "%shn_drive%:\%shn_path%\%1.shnf\%1_shn.md5"

::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
:dear_diary
echo %1 >> %shn_drive%:\%shn_path%\%1.shnf\%1_encode_notes.txt
echo.
if "%WINDIR%"=="C:\WINNT" for /f %%a in ('TIME /T') do set Time=%%a
if "%WINDIR%"=="C:\WINNT" echo encoded on %DATE% @ %Time%m >> %shn_drive%:\%shn_path%\%1.shnf\%1_encode_notes.txt
echo by %your_name% (%your_email%) >> %shn_drive%:\%shn_path%\%1.shnf\%1_encode_notes.txt
echo audio extraction:  %your_gear% >> %shn_drive%:\%shn_path%\%1.shnf\%1_encode_notes.txt
echo. >> %shn_drive%:\%shn_path%\%1.shnf\%1_encode_notes.txt
echo. >> %shn_drive%:\%shn_path%\%1.shnf\%1_encode_notes.txt
echo %adjustable_slogan% >> %shn_drive%:\%shn_path%\%1.shnf\%1_encode_notes.txt

echo. >> %shn_drive%:\%shn_path%\%1.shnf\%1_encode_notes.txt
echo. >> %shn_drive%:\%shn_path%\%1.shnf\%1_encode_notes.txt
echo.
:: PLEASE DON'T MODIFY THE LINES BELOW; LET ME HAVE MY FIFTEN MINUTES O' FAME...
echo ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >> %shn_drive%:\%shn_path%\%1.shnf\%1_encode_notes.txt
echo created with shn2k, the shorten compression assistant for windows 2000 and beyond >> %shn_drive%:\%shn_path%\%1.shnf\%1_encode_notes.txt
echo written by peter w. king ([email protected]) >> %shn_drive%:\%shn_path%\%1.shnf\%1_encode_notes.txt
echo (c)2001 crabcollective productions >> %shn_drive%:\%shn_path%\%1.shnf\%1_encode_notes.txt
echo ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >> %shn_drive%:\%shn_path%\%1.shnf\%1_encode_notes.txt

::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
:compression_tool_or_virus???
REM if exist c:\winnt\system32\shn2k.bat copy /Y c:\winnt\system32\shn2k.bat %shn_drive%:\%shn_path%\%1.shnf\shn2k.bat > nul

::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
:confirm_and_rip

::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
:last_gasp
explorer %shn_drive%:\%shn_path%\%1.shnf
echo finished -- thanks for using shn2k!
echo.

:end

::CLOSING CREDITS
::the win9x code doesn't trap errors as gracefully as it does in w2k
::so you might end up with a screenful of 'path not found' msgs -- 
::but only if your variables are misconfigured.  :-)
::
::there are no other known issues.  it works.  i am satisfied, for now.
::
::over and out,
::
::pwk
::
::  TODO for v1.00
::  windows9x date/time stamping
::  return to original DOS directory?
::  menu driven
::  turbo mode !!!
::  extract mode
::  autogenerate confirmation.bat script that both confirms and extracts for recipients

Five · #54 2020-02-18, 07:48 PM

omg do you remember etree rule #33???!!! this is why we don't consider wholefile md5 authoritative whatsoever.. it caused so much strife at etree before they cancelled rule #33. st5 checksums and Trader's Little Helper solved 99% of all these old issues by virtue of being valid across any lossless codec.

ffp/st5 and otherwise useful information such as st5 composite and shntool len check are excellent to see posted in the threads. wholefile .md5?? if you insist.

if you want to add embedded skt to shn and seed here to this day, it is okay just post ffp/st5 checksums they are not changed by this kind of activity.

shorten v3 page, retrieved from archive.org capture, 2002-10-17

Quote:

Originally Posted by etree.org

etree.org | shn v3 introduction

Shorten version 3 (SHN v3) allows Shorten users the ability to "audition" SHN files by jumping to different parts of the file using the slider control in Winamp (Windows users), or XMMS (Linux users). SHN v3 is (and always will be) 100% backward compatible! This means that older Shorten players and decoders will have no problem decoding Shorten files encoded with SHN v3.

Below is an evolving list of questions and answers about SHN v3. If you have any questions about SHN v3 that isn't answered below, please email serverxetree.org! We need your input!

etree.org | shn v3 q & a

What the heck are .skt files?

A .skt file is Shorten seek data.

Shorten seek data can either be embedded inside a Shorten file, or "live" outside the Shorten file. A .skt file is seek data that happens to "live" outside the Shorten file.

The reason for a separate seek data file is because the original seeder did not encode that particular show with Shorten v3. Re encoding the old Shorten file with the seek data embedded into it would change the MD5 checksum, and cause much confusion. Because of this, you should never append seek data to older Shorten files. You can create .skt files for your older (non seeking) Shorten files with SHN v3 tools.

.skt files are only necessary if you want to listen to Shorten files in ShnAmp or XMMS-SHN and be able to seek. Seeders that encode new shows with the SHN v3 tools will have seek data automatically embedded into the SHN file by default. The seek data is there so people can take advantage of seeking without needing additional (.skt) files.

Remember, SHN v3 (with or without the .skt files) will always be 100% backward compatible. This means you will always be able to decode any Shorten file with any Shorten decoder. The only difference between the different versions of Shorten is the ability to take advantage of new features (currently seeking).

Will creating .skt files change the MD5's of my Shorten files?

Creating .skt files will never affect the MD5 of your Shorten files. This is the whole purpose of .skt files; to avoid the potential nightmare of having two sets of MD5's floating around. Remember, creating .skt files is the ONLY way to seek-enable older SHN files.

What's this I'm hearing about rule #33?

Yes, there is indeed a new etree.org rule... Rule #33: Never append seek data to old (non-seeking) SHN files!!!!

Five · #55 2020-02-19, 06:06 PM

since 2005 we have .st5 checksums available from .shn sets using Trader's Little Helper (TLH), which can be compared for perfection against Flac Fingerprint (.ffp). Also noteworthy is that double-clicking an ffp file with TLH installed will compare and run self-test. Using Flac Frontend, you have to hit 'test' and 'fingerprint' then compare visually the checksums with other known sets to identify it. TLH modern way is great. Also, etree's current 'Flac Fingerprint' page is spot-on as of this writing, go look it up.

Blast from the past, showing some of the confusion upon the arrival of flac and understandable resistance of all the people who collected 10,000 GD/Phish shows in .shn format, using the poor standard of wholefile .md5 as opposed to current .ffp/.st5

keep in mind reading this that it is for the history, and also that .st5 we have been using since 2005 is the exact same checksums inside.

original etree wiki Flac Fingerprint page 2002-11-17
Thu, 02 Jan 2003 17:32:44 DianaHamilton [lma]

Quote:

Originally Posted by etree.org

Flac Fingerprint

A FLAC Fingerprint is a small text file (ffp.txt) that contains the filename and a printout of checksum information for one or more .flac files. The fingerprint is analogous to yet somewhat different from the .md5 files for used for Shorten (.shn):

Unlike an .md5 file, the FLAC Fingerprint ffp.txt file itself is not actually used in performing integrity checks on .flac files. Instead, FLAC automatically verifies each file against an internal checksum when you decompress.
The ffp.txt information is used to visually compare different .flac filesets for lineage purposes. Reference fingerprints can be listed in the ShnDatabase. In a similar way, the ShnDatabase lists .md5s as "fingerprints" for .shn filesets. In both cases, the [Internet Archive] also uses the fingerprints stored in the ShnDatabase to speed up their archiving of the music. So, it makes good sense to include a FLAC fingerprint file with each .flac seed.
A FLAC Fingerprint is generated only for the audio data portion of the file. This gives a truer reference point- just for the most important part of the file. In contrast, .md5s are generated against whole files, including extraneous or variable data (such as the seek tables on .shns).
SPECIAL NOTE ABOUT .MD5 FILES AND FLAC: It is a VERY bad idea to make an .md5 checksum file for a .flac fileset! Under FLAC, you can change the compression ratio and add/remove meta data to .flac files without changing the actual audio. The audio may be identical, but the extra data will completely change the .md5 checksum. This would cause major confusion when trying to compare the fileset against others in a database (similar to the current situation with nonseeking vs. seek-appended .shn files).
Repeat: Never make .md5 checksum files of .flac files. For .flac files, .md5s are useless as reference tools. Doing so will only cause unnecessary chaos and confusion.

See also: FLAC, FlacFrontend, SeedingGuidelines
This Page Last Changed: Nov 7, 2002 14:29:11

Five · #56 2020-02-19, 06:10 PM

be sure to check the link for Adam Fox's Shorten guide, still online as of this writing in 2020. amazing!

last updated 2001-11-13

batchfaq.txt by Jeremy Clark, 1999-04-26

Quote:

Subject: [pcp-shn] How to handle Shorten and MD5 my way.
Date: Mon, 26 Apr 1999 18:05:28 +0000
From: Jeremy Clark <RubyBroomxxxxxxxx.xxx>
To: PCP <[email protected]>, PCP-SHN <[email protected]>

From: Jeremy Clark <RubyBroomxxxxxxxx.xxx>

OK, I finally got my Shorten setup working perfectly with batch files
(thanks to Adam Fox's Shorten Guide), so I thought I'd share my method,
because I think it works rather nicely.

1. Create a folder on your C: drive called "util"

2. Create a folder on your C: drive called "burning"

3. Make sure there are copies of Shortn32.exe and md5sum.exe in the
"util" folder you created

4. Create the following 4 batch files in notepad and put them all in
the
"util" foler you created:

----------cut here-----------------
cls
lfnfor on
for %%f in (*.shn) do c:\util\shortn32.exe -x %%f c:\burning\%%f.wav
lfnfor off
----------cut here-----------------

name this file "unshorten.bat"

----------cut here-----------------
cls
lfnfor on
for %%f in (*.wav) do c:\util\shortn32.exe %%f c:\burning\%%f.shn
lfnfor off
----------cut here-----------------

name this file "shorten.bat"

----------cut here-----------------
c:\util\md5sum --binary *.shn > > ~NameMe~.md5
----------cut here-----------------

name this file "md5gen.bat"

----------cut here-----------------
cls
lfnfor on
for %%f in (*.md5) do c:\util\md5sum.exe --check %%f
lfnfor off
----------cut here-----------------

name this file "checksum.bat"

5. Open Windows Explorer and go to View>Options>File Types and click on
"New Type" and enter into the Description of type field "Shorten file"
and into the Associated extension field ".shn"

6. Create a "New..." action and call it "Extract". Put
"c:\util\shortn32.exe" -x "%1" "%1.wav" (WITH the quotes) into the
"application to perform action" field. Click on "Ok".

7. Create a "New..." action and call it "Extract all". Under
"application to perform action", browse to the file "unshorten.bat" you
created. Click on "Ok".

8. Create a "New..." action and call it "Generate MD5". Under
"application to perform action", browse to the file "md5gen.bat" you
created. Click on "Ok".

9. Back in View>Options>File Types, again click on "New Type" and enter
into the Description of type field "md5 checksum" and into the
Associated extension field ".md5"

10. Create a "New..." action and call it "check". Under "application to

perform action", browse to the file "checksum.bat" you created. Click
on "Ok".

11. Find "Wave sound" (or something similar) on the list of registered
file types and double click on it. Create a "New..." action and call it

"Shorten all". Under "application to perform action", browse to the
file "shorten.bat" you created. Click on "Ok".

12. Create a "New..." action and call it "Shorten". Under "application
to perform action", type "c:\util\shortn32.exe" "%1" "%1.shn" (WITH the
quotes). Click on "Ok".

Ok, now your system is set up to do the following:

1. Right click on a .shn file on a CDROM disc (or anywhere for that
matter) and choose "Extract all". All the shorten files in the current
directory will be sequentially extracted into .wav files in the
c:\burning directory.

2. Right click on a .shn file in a directory and choose "Generate MD5".
A file called "~NameMe~.md5" will be created in the c:\burning
directory. Rename the file appropriately.

3. Right click on an .md5 file in a directory and choose "check". A DOS

window will open and md5sum will sequentially verify that all the .shn
files in the directory match the .md5 file.

4. Simply double-click on any .shn file anywhere and it will decompress
to a .wav file.

5. Right click on a .wav file and choose "Shorten". A .shn file will be

created in the same directory.

OK I think I got it all typed in there. I hope all this helps! Feel
free to
email me with any questions, although I'm not really an expert.
I owe most of this to Adam Fox's Shorten guide
at http://members.tripod.com/~rimeswel/shnguide.html

--
Jeremy Clark
AOL Instant Messenger - RubyBroom
ICQ# - 7534422
IRC nicks - ]eremy, RubyBroom

Five · #57 2020-02-19, 07:22 PM

the batch files posted below really give a window into how we used to do things back in the day.

shortn32.exe description and tutorial by Mike Wren, 2000-10-19

Quote:

Originally Posted by etree.org

etree.org | shortn32.exe introduction

Shorten® (.shn) is an audio compression scheme that is used to compress audio (.wav) files losslessly. This means that after you decompress a Shorten file, everything that was in the original .wav is there. This is unlike MP3, in which the compression step throws away information that can never be recovered.

For distribution and archiving purposes, the Shorten (.shn) files themselves can also be burned onto a CD-R as data. One big advantage to archiving Shorten files is that you'll never have to deal with digital audio extraction (DAE) from an audio disc, which can sometimes produce clicks and other undesired artifacts.

The Shorten source code is the property of SoftSound Limited and has been made available to the general public for non-commercial use. The original SoftSound code has been extended by etree.org (most notably by the work of Wayne Steilau and Jason Jordan) to include "seek-tables" so that you can easily skip to any portion of a song in audio players like WinAmp and XMMS. The latest version of Shorten can always be found on the etree.org shnutils page or the FreshMeat project page.

For Windows users who wish to use a command line version of Shorten, you've come to the right place! When shortn32.exe is used along with the etree.org batch files, it's surprisingly robust and easy to use, minus all the bells and whistles of a graphical user interface.

etree.org | shortn32.exe download

This is the official distribution site for SHN v3 (seeking SHN)

shorten-3.5.1.zip v3.5.1 (Cygwin) - 440KB Released 2/12/03
[color=blue][u]Cygwin version of Shorten. Works on Windows 9x/ME/NT/XP.

shortn32.exe v3.1 OLD - 99KB Released 10/10/00 31336 Downloads since 10/10/00

etree.org batch files - 3KB Updated 8/20/02 10478 Downloads since 10/9/00
These batch files will work for Windows users ONLY!

etree.org | shortn32.exe installation

You will want to replace your existing shortn32.exe file.

Windows 95/98: Download shortn32.exe to c:\windows\command

Windows NT/2000: Download shortn32.exe to c:\winnt\system32

To find out what version of shortn32.exe you are currently using, open an MS-DOS window and type:

shortn32 -h

The version number will be at the top.

If you downloaded the [color=blue]etree.org batch files for Windows[/blue], extract the three batch files (compress.bat, decompress.bat, makeskt.bat) to the directory: c:\windows\command

etree.org | shortn32.exe usage, extracting

To extract .shn files to .wav files (for burning to CD-R), open an MS-DOS window, go into the directory where the .shn files are located, and type the following:

shortn32 -x [filename].shn [filename].wav

You must insert the names of the .shn files [without the brackets]. Example:

shortn32 -x ph94-06-26d1t01.shn ph94-06-26d1t01.wav

The first file (.shn) is your input file, the last file (.wav) is your output file. You will have to repeat this process for each SHN file in the directory, unless you are using the etree.org batch files.

If you're using the etree.org batch files, open an MS-DOS window and go to the directory you wish to extract from SHN to WAV. Type: "decompress" (without quotes). The batch file will prompt you what drive you wish to save the WAV files to.

etree.org | shortn32.exe usage, compressing

After making sure you have downloaded and copied shortn32.exe into the proper directory (see installation), open an MS-DOS window and go to the directory of the show you wish to compress into Shorten format.

Type:

shortn32 [filename].wav [filename].shn

You must insert the names of the .shn files [without the brackets]. Example:

shortn32 ph94-06-26d1t01.wav ph94-06-26d1t01.shn

The first file (.wav) is your input file, the last file (.shn) is your output file. You will have to repeat this process for each file in the directory, unless you are using the etree.org batch files. Also, if you are using Shorten v3.0 or above, any SHN's you compress will have seek data embedded into the SHN file by default. Please encode the seek data to the Shorten files if you are creating/seeding a new show!

If you're using the etree.org batch files, open an MS-DOS window and go to the directory you wish to convert to SHN. Type: "compress" (without quotes). The batch file will prompt you what drive you wish to save the Shorten files to.

etree.org | shortn32.exe usage, creating seek

If you have older SHN files that are not SHN v3 (seek) enabled, you can manually create seek data for these files!!! The easiest way to do this is by using the etree.org batch files.

Open an MS-DOS window and go to the directory containing the SHN files you want to create seek files for.

Type: "makeskt" (without quotes). The batch file will then create and save in that same directory a seek (.skt) file for each SHN file. It's that easy!

etree.org | shortn32.exe etcetera

When compressing new Shorten files, please remember to follow the etree.org naming scheme, and also make sure you are using the most recent version of Shorten!

etree.org | shortn32.exe credits

Special thanks to Wayne Stielau, the creator of SHN v3. All documentation written and updated by Mike Wren.

complete contents of batch.zip

readme.txt

Code:

Shorten® Batch Utilites for Windows® 95/98
Written by Terrapin, Updated for SHN v3 by Mike Wren.

10/9/00

http://etree.org · Leading the Lossless Audio Revolution!

Special Thanks to Wayne Stielau for creating the SHN v3
standard for the etree.org community.




Installation:

First, make sure you have the most recent version of 
shortn32.exe in your c:\windows\command directory.  Extract 
the three batch files (compress.bat, decompress.bat and 
makeskt.bat) to the c:\windows\command directory.



Usage:

Compressing - Open an MS-DOS window and go to the directory 
you wish to convert to SHN.  Type: "compress" (without quotes).
The batch file will prompt you what drive you wish to save the 
Shorten files to.

Extracting - Open an MS-DOS window and go to the directory
you wish to extract from to SHN to WAV.  Type: "decompress"
(without quotes).  The batch file will prompt you what drive
you wish to save the WAV files to.

Creating Seek (.skt) files - If you have older SHN files you
want to make seek indexes for, you can do so with this new
batch file.  Open an MS-DOS window and go to the directory
containing the SHN files you want to create seek files for.  
Type: "makeskt" (without quotes). The batch file will then 
create and save in that same directory seek (.skt) files for 
each SHN file.


Updates:

Don't forget to check http://etree.org/software.html regularly 
for software updates.  For questions or comments about these
batch utilitites, please email Mike Wren < [email protected] >.


--------------------------------------------------------------

Etree.org is the leader in lossless digital audio distribution 
on the Internet! We are a community committed to providing the 
highest quality live concerts in a lossless, downloadable format.

You can find every band that allows taping in the jambands 
community on etree.org, including Phish, the Grateful Dead, 
String Cheese Incident, The Slip, Medeski, Martin & Wood, 
Umphrey's McGee, The Big Wu, Amphibian and The New Deal.

To use Etree.org, all you need is a high speed Internet 
connection (cable modem, xDSL, T1, or Ethernet) and a CD-R burner. 
Etree.org uses Shorten (.shn) audio compression because it creates 
an exact clone of the original DAT source.

We do not use MP3 due to it's lossy compression scheme which 
greatly degrades from the quality of the music. If you trade a 
CD-R burned from MP3 audio, you're polluting the CD-R trading 
community.

Etree.org gives everyone the means to easily create and trade music 
with no loss of quality. Best of all, it's all FREE!

compress.bat

Code:

@echo off
cls
echo WAV to SHN batch compression utility for Windows 95/98
echo Written by Terrapin ú Updated for SHN v3 by Mike Wren 
echo ÿ
echo http://etree.org ú Leading the Lossless Audio Revolution
echo ÿ
echo ÿ
lfnfor on
choice /c:CDEFGHIJKLMNOPQRSTUVWXYZA /N Select a drive letter to compress to:ÿ

if errorlevel 25 goto end
if errorlevel 24 goto z
if errorlevel 23 goto y
if errorlevel 22 goto x
if errorlevel 21 goto w
if errorlevel 20 goto v
if errorlevel 19 goto u
if errorlevel 18 goto t
if errorlevel 17 goto s
if errorlevel 16 goto r
if errorlevel 15 goto q
if errorlevel 14 goto p
if errorlevel 13 goto o
if errorlevel 12 goto n
if errorlevel 11 goto m
if errorlevel 10 goto l
if errorlevel 9 goto k
if errorlevel 8 goto j
if errorlevel 7 goto i
if errorlevel 6 goto h
if errorlevel 5 goto g
if errorlevel 4 goto f
if errorlevel 3 goto e
if errorlevel 2 goto d
if errorlevel 1 goto c


:C
@echo on
FOR "%%f" in (*.wav) DO shortn32 "%%f" "c:\%%f.shn"
@echo off
goto end

:D
@echo on
FOR "%%f" in (*.wav) DO shortn32 "%%f" "d:\%%f.shn"
@echo off
goto end

:E
@echo on
FOR "%%f" in (*.wav) DO shortn32 "%%f" "e:\%%f.shn"
@echo off
goto end

:F
@echo on
FOR "%%f" in (*.wav) DO shortn32 "%%f" "f:\%%f.shn"
@echo off
goto end

:G
@echo on
FOR "%%f" in (*.wav) DO shortn32 "%%f" "g:\%%f.shn"
@echo off
goto end

:H
@echo on
FOR "%%f" in (*.wav) DO shortn32 "%%f" "h:\%%f.shn"
@echo off
goto end

:I
@echo on
FOR "%%f" in (*.wav) DO shortn32 "%%f" "i:\%%f.shn"
@echo off
goto end

:J
@echo on
FOR "%%f" in (*.wav) DO shortn32 "%%f" "j:\%%f.shn"
@echo off
goto end

:K
@echo on
FOR "%%f" in (*.wav) DO shortn32 "%%f" "k:\%%f.shn"
@echo off
goto end

:L
@echo on
FOR "%%f" in (*.wav) DO shortn32 "%%f" "l:\%%f.shn"
@echo off
goto end

:M
@echo on
FOR "%%f" in (*.wav) DO shortn32 "%%f" "m:\%%f.shn"
@echo off
goto end

:N
@echo on
FOR "%%f" in (*.wav) DO shortn32 "%%f" "n:\%%f.shn"
@echo off
goto end

:O
@echo on
FOR "%%f" in (*.wav) DO shortn32 "%%f" "o:\%%f.shn"
@echo off
goto end

:P
@echo on
FOR "%%f" in (*.wav) DO shortn32 "%%f" "p:\%%f.shn"
@echo off
goto end

:Q
@echo on
FOR "%%f" in (*.wav) DO shortn32 "%%f" "q:\%%f.shn"
@echo off
goto end

:R
@echo on
FOR "%%f" in (*.wav) DO shortn32 "%%f" "r:\%%f.shn"
@echo off
goto end

:S
@echo on
FOR "%%f" in (*.wav) DO shortn32 "%%f" "s:\%%f.shn"
@echo off
goto end

:T
@echo on
FOR "%%f" in (*.wav) DO shortn32 "%%f" "t:\%%f.shn"
@echo off
goto end

:U
@echo on
FOR "%%f" in (*.wav) DO shortn32 "%%f" "u:\%%f.shn"
@echo off
goto end

:V
@echo on
FOR "%%f" in (*.wav) DO shortn32 "%%f" "v:\%%f.shn"
@echo off
goto end

:W
@echo on
FOR "%%f" in (*.wav) DO shortn32 "%%f" "w:\%%f.shn"
@echo off
goto end

:X
@echo on
FOR "%%f" in (*.wav) DO shortn32 "%%f" "x:\%%f.shn"
@echo off
goto end

:Y
@echo on
FOR "%%f" in (*.wav) DO shortn32 "%%f" "y:\%%f.shn"
@echo off
goto end

:Z
@echo on
FOR "%%f" in (*.wav) DO shortn32 "%%f" "z:\%%f.shn"
@echo off
goto end

:end
echo ÿ
echo Compression complete!
echo ÿ
lfnfor off

decompress.bat

Code:

@echo off
cls
echo SHN to WAV batch decompression utility for Windows 95/98
echo Written by Terrapin ú Updated for SHN v3 by Mike Wren 
echo ÿ
echo http://etree.org ú Leading the Lossless Audio Revolution!
echo ÿ
echo ÿ
lfnfor on
choice /c:CDEFGHIJKLMNOPQRSTUVWXYZA /N Select a drive letter to decompress to:ÿ

if errorlevel 25 goto end
if errorlevel 24 goto z
if errorlevel 23 goto y
if errorlevel 22 goto x
if errorlevel 21 goto w
if errorlevel 20 goto v
if errorlevel 19 goto u
if errorlevel 18 goto t
if errorlevel 17 goto s
if errorlevel 16 goto r
if errorlevel 15 goto q
if errorlevel 14 goto p
if errorlevel 13 goto o
if errorlevel 12 goto n
if errorlevel 11 goto m
if errorlevel 10 goto l
if errorlevel 9 goto k
if errorlevel 8 goto j
if errorlevel 7 goto i
if errorlevel 6 goto h
if errorlevel 5 goto g
if errorlevel 4 goto f
if errorlevel 3 goto e
if errorlevel 2 goto d
if errorlevel 1 goto c

:C
@echo on
FOR "%%f" in (*.shn) DO shortn32 -x "%%f" "C:\%%f.wav"
@echo off
goto end

:D
@echo on
FOR "%%f" in (*.shn) DO shortn32 -x "%%f" "D:\%%f.wav"
@echo off
goto end

:E
@echo on
FOR "%%f" in (*.shn) DO shortn32 -x "%%f" "E:\%%f.wav"
@echo off
goto end

:F
@echo on
FOR "%%f" in (*.shn) DO shortn32 -x "%%f" "F:\%%f.wav"
@echo off
goto end

:G
@echo on
FOR "%%f" in (*.shn) DO shortn32 -x "%%f" "G:\%%f.wav"
@echo off
goto end

:H
@echo on
FOR "%%f" in (*.shn) DO shortn32 -x "%%f" "H:\%%f.wav"
@echo off
goto end

:I
@echo on
FOR "%%f" in (*.shn) DO shortn32 -x "%%f" "I:\%%f.wav"
@echo off
goto end

:J
@echo on
FOR "%%f" in (*.shn) DO shortn32 -x "%%f" "J:\%%f.wav"
@echo off
goto end

:K
@echo on
FOR "%%f" in (*.shn) DO shortn32 -x "%%f" "K:\%%f.wav"
@echo off
goto end

:L
@echo on
FOR "%%f" in (*.shn) DO shortn32 -x "%%f" "L:\%%f.wav"
@echo off
goto end

:M
@echo on
FOR "%%f" in (*.shn) DO shortn32 -x "%%f" "M:\%%f.wav"
@echo off
goto end

:N
@echo on
FOR "%%f" in (*.shn) DO shortn32 -x "%%f" "N:\%%f.wav"
@echo off
goto end

:O
@echo on
FOR "%%f" in (*.shn) DO shortn32 -x "%%f" "O:\%%f.wav"
@echo off
goto end

:P
@echo on
FOR "%%f" in (*.shn) DO shortn32 -x "%%f" "P:\%%f.wav"
@echo off
goto end

:Q
@echo on
FOR "%%f" in (*.shn) DO shortn32 -x "%%f" "Q:\%%f.wav"
@echo off
goto end

:R
@echo on
FOR "%%f" in (*.shn) DO shortn32 -x "%%f" "R:\%%f.wav"
@echo off
goto end

:S
@echo on
FOR "%%f" in (*.shn) DO shortn32 -x "%%f" "S:\%%f.wav"
@echo off
goto end

:T
@echo on
FOR "%%f" in (*.shn) DO shortn32 -x "%%f" "T:\%%f.wav"
@echo off
goto end

:U
@echo on
FOR "%%f" in (*.shn) DO shortn32 -x "%%f" "U:\%%f.wav"
@echo off
goto end

:V
@echo on
FOR "%%f" in (*.shn) DO shortn32 -x "%%f" "V:\%%f.wav"
@echo off
goto end

:W
@echo on
FOR "%%f" in (*.shn) DO shortn32 -x "%%f" "W:\%%f.wav"
@echo off
goto end

:X
@echo on
FOR "%%f" in (*.shn) DO shortn32 -x "%%f" "X:\%%f.wav"
@echo off
goto end

:Y
@echo on
FOR "%%f" in (*.shn) DO shortn32 -x "%%f" "Y:\%%f.wav"
@echo off
goto end

:Z
@echo on
FOR "%%f" in (*.shn) DO shortn32 -x "%%f" "Z:\%%f.wav"
@echo off
goto end

:end
echo ÿ
echo Decompression complete - Enjoy the music!
echo ÿ
lfnfor off

makeskt.bat

Code:

@echo off
cls
echo Seeking Shorten batch creation utility for Windows 95/98
echo Written for SHN v3 by Mike Wren
echo ÿ
echo http://etree.org ú Leading the Lossless Audio Revolution
echo ÿ
echo ÿ
echo Working...
echo ÿ
lfnfor on

FOR "%%f" in (*.shn) DO shortn32 -s "%%f" "%%f.shn"
goto end

:end
echo ÿ
echo Seek (.skt) files successfully created and saved
echo in the same directory as your Shorten files.
echo ÿ
lfnfor off

makeskt2k.bat

Code:

@echo off
cls
echo Seeking Shorten batch creation utility for Windows 2K/XP
echo Written for SHN v3 by Mike Wren
echo Updated for Win2K/XP By Rich Denis
echo ÿ
echo http://etree.org ú Leading the Lossless Audio Revolution
echo ÿ
echo ÿ
echo Working...
echo ÿ


FOR %%f in (*.shn) DO shortn32 -s %%f %%f
goto end

:end
echo ÿ
echo Seek (.skt) files successfully created and saved
echo in the same directory as your Shorten files.
echo ÿ

Five · #58 2020-02-19, 09:16 PM

legacy software Etree Menu, last updated 2001-02-24

Quote:

Originally Posted by Eddie Burks

Ed's Page

Eddie Burks
Current project: "batch" programming for SHN/MD5 Menu association in Win9X and once again NT 4.0

Ebshn is now EtreeMenu

It also now has a completely automatic installer
Free software: get Etreemenu now karma-ware
Easy menus for making SHN's and MD signatures
Icons for SHN and MD files, Your SHN's will seek in SHNAMP
Makes seek tables for older SHN's, uses Shortn32.exe v3.1
Current installer EtreeMenu212c.exe has 2 level user input
Enjoy! Eddie Burks GOT MOOK?

download ~750K EtreeMenu save as .EXE

second site

update history -- screenshot

Juno bans exe files so I spelled EXE, ZIP; The mirror sometimes has odd performance. Whatever site you use, SAVE the file as EtreeMenu.EXE
User input batch file has been rewritten to work with Win9X and NT 4.0. There is now an install option for 9X or NT4.0 since different files are needed.

someone please test 9X & NT install option in Win ME, Uninstall between tries
There is NO Win2K support

Features:

Network drives (that are mapped to a drive letter) may be
used. A new feature lets you supply drive and folder names.

right click to:

create .skt (seek) files for all SHN's in a folder
compress all waves in folder (you specify destination)
uncompress all shn's in folder (you specify destination)
compress 1 wave destination is the same folder
uncompress 1 shn destination is the same folder
check ALL MD5's in folder
check 1 selected MD5
create md5 for waves
create md5 for shns
Play a Wave in Winamp (Winamp must be installed)
Play SHN's in Winamp (Winamp must be installed with
the SHNAMP Plugin)

NO redundant file extensions (trackname.shn.wav.shn.wav)

Fully uninstallable via the control panel at any time
(All etreemenu items will be removed from Context Menus)

---------------------------------------------------------------

EtreeMenu Requires: access to c:\
(for temp files and installation to C:\Program Files)

---------------------

Correct EtreeMenu implementation of SHNAMP requires:

1) Select Custom Setup Type during EtreeMenu install
and check "Winamp Menu"

2) Winamp is installed in C:\Program Files\Winamp

3) SHNAMP plugin is installed
See http://www.etree.org/shnamp.html

4) Configure Winamp's preferences so that SHN and WAV
are NOT SELECTED in Winamp file types. Winamp will
steal control of the Wave and SHN file associations
if you get this wrong and you will not get EtreeMenus.

Configuring Winamp's preferences:
Open Winamp. Open preferences [Ctrl P] look at file types.
On my Winamp file types, selected items are shaded in BLUE.
SHN and WAV should NOT BE SHADED IN BLUE.

Links

The Official Shnamp Page

Exact Audio Copy -EAC-

CDWave Wave Splitter/Recorder
While doing DAT>HD CDWave does not thrash on your Harddrive like SoundForge

How to EXACTLY verify proper EAC extraction using EtreeMenu

CoolEdit 96 2Mb direct download (c)1992-1996 Syntrillium Software shareware wave editor

CoolEdit 96/2000/Pro emphasis/de-emphasis Filter by Eddie Burks cool.ini zipped

This will allow you to fix music that was digitally cloned with the emphasis bit improperly flagged. This has occurred with some old PCM transfers and with some DAT to DAT transfers (some SCMS strippers and AES/EBU to SPDIF converters could have caused this.

Winamp

Adam Fox' Shorten Guide

The Official Shnamp Page

Greg & Diana Hamilton's Shorten and md5sum FAQ.

CLEAN UP!
So, you have installed Etreebeta043, Winamp plugins, Ebshnbetas, 3 different mp3 decoders and a half dozen other programs that all gave you additional stuff in context menus. This put invisible clutter in your registry and visible clutter in your menus. The etreebeta uninstaller does not remove it's registry entries.

NOW
EtreeMenu has a nice automatic installer and a nice automatic uninstaller too. This uninstaller will remove
all EtreeMenu associations. To restore things to original state though you should uninstall and reinstall the Windows Sound Recorder so that any old stuff in your wave menu will be cleaned out. Then you can reinstall whatever you have found that works for you and have a nice clean setup.

[image missing]

This page was last updated on: February 24, 2001

[Createyourownwebsiteathome.juno.com!]

update.txt

Code:

update history

EtreeMenu212c.exe compiled 2/12/2001

Added 2nd level of folders for user input
you may now direct files to a drive a folder
AND a subfolder ie  c:\thisistheplace\disc1

EtreeMenu212.exe compiled 2/08/2001

New input routines using senvar.com for 9X and
qbasic for NT4.0. This install contains a
selectable WIN9x or NT4.0 install. This version
does not support Win2K  (might work with Win ME)


EtreeMenu210.exe compiled 2/5/2001

Fixed bug that caused most Win98 installs to fail
to work (user input feature problem) Rewrote input. 
Added make SKT files for older SHN's. This program is 
still NOT certified for NT, ME, and 2K, it will probably 
work for them if the executable and com files are 
on the default path. If the input senvar.com is not
compatible the batch files could be changed to omit the
input script.


EtreeMenu123.exe compiled 8/25/2000 and 1/23/2001

Renamed, revamped, new InstallShield Installer/Uninstaller
user input drive and folder destination for extracted file 
Shorten v3.1 (seekable) engine  SHNAMP compatible
32bit win9x console based;  only tested for Win95 Win98 

ebshn_bXXX.exe    md5 and shorten for WIN9X  NT4.0

b725.1 7/25/00 

Removed default shn/md5 additions to winamp; made them options

b725   7/25/00

Added Menu_set folder with info for setting up the following:

all menus on machines with Winamp (and the SHN plugin) installed
all menus on machines without Winamp (my standard install)
Just the menus for MD5 on wave files only  (for EAC verification) 

b721   7/21/00

OOPS... sorry, even though the programming works fine in NT.40,  I was
distributing the program in an NT incompatible archive.
New SFX archive format is Windows based and fully NT4.0 ready 

Slight icon changes, credits for icons to Jeremy Clark

Some cosmetic changes to batch files


b717   7/17/00

New icon added for MD5 this has the big check mark

Revised some documentation and batch file text comments

Added info about installing over etreesetup0_43b

Finished Documenting SHNCD setup (in the eb-tree\shncd  folder)
This shows you how to make autoextract SHN CDS's for newbys 


b715   7/15/00

a slightly different md5icon 
(but no larger lettering or big check yet   :-) :-) :-)

added the edit function to md5file menu

set all etree related files to always show extension


b714    7/14/00  

this archive should have all the expected syntax for NT4.0
it would still be best to delete    lfnfor on    and   lfnfor off
from NT batch files as this is not needed or supported in NT4.0
(they ARE required for WIN9X)

an md5file icon was added
I would still like to see larger lettering for this icon
and/or a big checkmark very visible over the disc

(anything to make it more recognizable if viewing files as
small icons)

eacmd5.txt [not accurate]

Code:

right click to perform the following on extracted wave file folders

To assure perfect extraction with EAC you extract all files 
twice into separate folders , create an MD signature for 1 set. 
Move this MD5 file to the other folder of extracted files and check
MD5 (compare 2nd set of files to the 1st set). If all files verify
you are assured to have a perfect EAC extraction. Files that fail 
should be extracted again; if you can change the extract conditions
for the failed files this may help.

coolini.txt

Code:

Cut and paste the stuff from this cool.ini file to get my filter

You may have to finesse this into your cool.ini (in Windows folder)
by changing the [Filters96] heading to match your version

First I would just paste the whole section in as is and 
see what happens; backup your existing cool.ini

Eddie Burks

cool.ini

Code:

; add the section below to your cool.ini file in Windows folder
; you may have to change [Filters96] to match your version
; the filters I made are the last 2

[Filters96]
Item1=Treble Boost,3,7,0,50,9305,49,10441,53,11577,64,12599,71,13885,75,16384,76,2,0,50,16384,50,2,0,800,1,2,0,0,1000,100,3,0,100,-15,15,1600,1,0,1
Item2=Morph low to high,3,9,0,50,1322,51,2106,59,2831,70,3744,70,4424,63,5093,54,6617,49,16384,50,7,0,50,2831,50,6959,52,9721,56,10895,67,12031,72,16384,73,2,1,400,0,4,0,0,648,31,831,57,1000,100,3,0,100,-15,15,1600,2,1,1
Item3=Super-High End Boost,3,9,0,50,13280,50,13999,53,14377,59,14836,70,15205,80,15484,84,15887,85,16384,85,9,0,26,0,25,0,27,278,34,527,46,958,56,1563,67,2693,72,16384,73,2,1,400,1,4,0,0,648,31,831,57,1000,100,3,0,100,-20,20,1600,2,1,1
Item4=Low Pass 5512 Hz,3,4,0,100,4095,100,4096,0,16384,0,4,0,100,8192,100,8193,0,16384,0,1,1,400,1,4,0,0,648,31,831,57,1000,100,3,0,100,-20,20,1600,2,1,0
Item5=Ringing A's,3,30,0,0,3628,0,3629,100,4059,100,4060,0,5382,0,5382,100,5585,100,5585,0,7073,0,7073,100,7182,100,7182,0,8741,0,8741,100,8795,100,8795,0,10381,0,10382,100,10435,100,10436,0,12033,0,12034,100,12060,100,12061,0,13671,0,13672,100,13698,100,13699,0,16384,0,9,0,26,0,25,0,27,0,34,278,46,752,56,1405,67,2596,72,16384,73,1,1,1024,1,4,0,0,648,31,831,57,1000,100,3,0,100,-18,18,4096,2,1,1
Item6=Low Pass 11025 Hz,3,4,0,100,8192,100,8193,0,16384,0,4,0,100,8192,100,8193,0,16384,0,1,1,400,1,4,0,0,648,31,831,57,1000,100,3,0,100,-20,20,1600,2,1,0
Item7=Low Pass 4000 Hz,3,4,0,100,2972,100,2973,0,16384,0,4,0,100,8192,100,8193,0,16384,0,1,1,400,1,4,0,0,648,31,831,57,1000,100,3,0,100,-20,20,1600,2,1,0
Item8=Sub-Woofer Boost,3,11,0,50,642,51,1236,60,1563,73,2044,81,2596,85,3349,87,3774,79,4029,60,4599,51,16384,50,11,0,50,143,50,527,58,958,77,1322,94,1711,94,2106,88,2336,64,2547,53,3003,50,16384,50,2,1,1024,1,4,0,0,648,31,831,57,1000,100,3,0,100,-20,20,4096,2,1,1
Item9=Telephone Bandpass,3,6,0,0,4424,0,4740,100,11964,100,12100,0,16384,0,6,0,100,1981,100,1981,0,2740,0,2740,100,16384,100,1,0,1024,1,2,0,0,1000,100,3,0,100,-15,15,2048,1,0,1
Item10=Treble Reduce,3,7,0,50,9837,50,11010,48,11994,43,12751,35,13432,31,16384,31,7,0,50,12233,50,14359,52,15149,56,15418,67,15653,72,16384,73,2,1,256,1,4,0,0,648,31,831,57,1000,100,3,0,100,-15,15,1024,2,1,1
Item11=Loudness,3,19,0,50,1054,50,1485,58,1916,71,2547,76,3201,77,3804,73,4185,65,4556,57,5557,52,6544,50,13279,50,13998,53,14376,59,14755,66,15172,71,15563,75,15966,76,16384,76,9,0,26,0,25,0,27,143,34,406,46,857,56,1485,67,2645,72,16384,73,2,1,512,1,4,0,0,648,31,831,57,1000,100,3,0,100,-18,18,2048,2,1,1
Item12=Bass Boost,3,11,0,50,527,51,1711,56,2336,67,2918,77,3619,78,4259,76,4915,68,5515,57,6765,50,16384,50,11,0,50,527,51,1147,60,1485,73,1981,81,2547,85,3313,87,3744,79,4002,60,4578,51,16384,50,2,1,1024,1,4,0,0,648,31,831,57,1000,100,3,0,100,-15,15,4096,2,1,1
Item13=Bass Cut,3,11,0,50,567,43,1286,36,2043,31,2875,27,3594,25,4389,29,5032,39,5751,48,6765,50,16384,50,11,0,50,527,51,1147,60,1485,73,1981,81,2547,85,3313,87,3744,79,4002,60,4578,51,16384,50,2,1,1024,1,4,0,0,648,31,831,57,1000,100,3,0,100,-15,15,4096,2,1,1
Item14=60Hz Notch,3,6,0,100,2215,100,2216,0,2611,0,2612,100,16384,100,6,0,100,2215,100,2216,0,2611,0,2612,100,16384,100,1,0,12000,1,2,0,0,1000,100,2,0,100,-15,15,24000,1,0,1
Item15=50Hz Notch,3,6,0,100,1742,100,1743,0,2216,0,2217,100,16384,100,6,0,100,1742,100,1743,0,2216,0,2217,100,16384,100,1,0,12000,1,2,0,0,1000,100,2,0,100,-15,15,24000,1,0,1
Item16=60Hz + 120Hz Notch,3,10,0,100,2215,100,2216,0,2611,0,2612,100,3960,100,3961,0,4157,0,4158,100,16384,100,10,0,100,2215,100,2216,0,2611,0,2612,100,3960,100,3961,0,4157,0,4158,100,16384,100,1,0,12000,1,2,0,0,1000,100,2,0,100,-15,15,24000,1,0,1
Item17=50Hz + 100Hz Notch,3,10,0,100,1742,100,1743,0,2216,0,2217,100,3507,100,3508,0,3744,0,3745,100,16384,100,10,0,100,1742,100,1743,0,2216,0,2217,100,3507,100,3508,0,3744,0,3745,100,16384,100,1,0,12000,1,2,0,0,1000,100,2,0,100,-15,15,24000,1,0,1
Item18=de-emphasis  (dat),3,21,0,50,3587,50,8429,51,8886,51,9150,52,10707,57,11653,62,12392,68,12919,73,13310,77,13697,81,14015,84,14269,86,14522,88,15468,94,15624,95,15770,96,15907,97,16037,97,16166,98,16384,98,2,0,50,16384,50,2,0,6400,1,2,0,0,1000,100,3,0,100,10,-10,12800,1,0,1
Item19=emphasis  (dat),3,21,0,50,3587,50,8429,51,8886,51,9150,52,10707,57,11653,62,12392,68,12919,73,13310,77,13697,81,14015,84,14269,86,14522,88,15468,94,15624,95,15770,96,15907,97,16037,97,16166,98,16384,98,2,0,50,16384,50,2,0,6400,1,2,0,0,1000,100,3,0,100,-10,10,12800,1,0,1

untitled.txt

Code:

If you really like and use EtreeMenu and you are in the
shrinking number of persons who CAN,  please consider
giving blood... frequently. Many people  can no longer 
give blood due to the hepatitis epidemic in the USA. 
And as Phil Lesh also asks... consider signing an 
organ donor card and discuss it with your family.

Five · #59 2020-02-19, 10:30 PM

legacy software shnclick windows right-click context menu frontend for shntool, last update circa 2003-07-28

it came from Canada

Quote:

Originally Posted by ctree.org

shnclick

shnclick is a windows right-click context menu frontend for shntool. It is solely intended to provide quick access to common shntool tasks like checking and fixing sector boundaries on shorten files or stripping excess header info before seeding.

It enables a user to avoid the command line interface, and access basic shntool functionality from within the windows explorer shell by right-clicking one of a set of shorten files.

More advanced useage will require using the command line.

There's a picture here.

Requirements

shnclick works with 98 and 2000, and now even XP.
shnclick requires mkwACT to be installed prior to loading shnclick. You can find mkwACT here.

Installation

shnclick comes as a windows executable install routine, and strives to avoid clobbering existing file associations.
The uninstall routine is registered in the windows control panel "Add and Remove Software" section.

shnclick will install the following dependant software into your system directory:

shntool 1.2.2
shorten 3.5.1
cygwin.dll

Where's it at?

Right here:

Version 0.0.4 shnclick-0.0.4.exe 505KB shn files only
Version 0.0.4-wav shnclick-0.0.4-wav.exe 505KB with wav file support

Please send feedback to bobby at geewow dot net.

Five · #60 2020-02-19, 10:41 PM

ctree.org, circa 2002-06-04

CDRs used to be this important...

Quote:

Originally Posted by bobby GeeWOW

bobby geeWOW's CDR Rant..

This is basically a general overview of CDR technology culled from a buncha sources. Its intended to pull together all the divergent bits of info out there and kind of put things into context for joe non-computer-professional lotus-eating shorten trader.

While I do of course degenerate into offering my own deluded opinions here and there, I urge you bear in mind that I know nothing and claim no expertise in anything whatsoever - except for some propensity towards maximising sheer wonder and enjoyment in the beauty this great country of ours is blessed with.

So set yer bullshit filters to fine grained and kick back if yer gunna read it, 'cause this got WAY longer than I thought:

Episode 1 Is a general introduction to CDR technology.
Episode 2 Gets into the technology in a little more depth in order to address some of my ludicrous claims.
Episode 3 Here come things like the Plextor/Mitsui fetish.
Episode 4 Deals with software. Yowtch, get yer flame retardent ready..

If you have any comments/questions/open redicule to offer, please direct them to me or the list.

Episode 1: Myths and Facts in CDR burning.

First off the accelerated age testing that supported the industry's claim of 100 year CDR life spans turned out to be rediculous in the real world. And remember when they hyped us with the "you can scratch the bejeesus out of a CD and still play it so forget about albums" spiel?

Basically when you burn a disk the laser discolours the dyes on the disk in such a fashion that the data on them will be recognized and read for playback. Turns out that light and heat over the life of a disk will continue to change the state of these dyes until they eventually, and inevitably, become unreadable. I have a large batch of 3 year old audio disks burned to cheapo CDR's that are starting to just fail to play back audio at all - sitting happily ensconced in the darkness of binders at room temperature. Then hold a disk that's just been whizzing around for a while in your computer's CDOM drive between the palm of your hands...

So there are two basic types of disks:

Cyanine dye (type 0 and type 1) or Azo disks use a `long write' strategy type: low laser power for long periods of time. Typically blue in color.

Phtalocyanine dye use a `short write' strategy type: high laser power for a short time. This corresponds to the increasing speed at which modern burners operate. Typically light greeny/goldish in color.

By the way, Verbatim has the patent on Azo, Mitsui on Phtalocyanine, and Tayo Yuden has Cyanine (also the first CDR's made and the basis of the "Orange Book" specifications).

There are also key differences in what happens when yer burning the disks: Cyanine dyes, the original, do a phase change which discolours the burned parts that a reader then decodes into the ones and zeros that make up digital audio or data. I urge the gentle reader to think about this and picture just how "permanent" such a disk will be.

When Phtalocyanine disks are burned, a lower layer oozes up and hardens, actually imitating the pits of a real silver factory pressed disk. As you can imagine, these disks will be more robust and tolerant to environmental changes, as well as give the reading laser a little more to bite on.

On to the chaos:

Bear in mind there are a lot of factors involved when performing a burn - ambient temperature, temperature in the burner, type of dye on the disk, write strategy, humidity (go ahead and laugh..), speed of rotation, etc.

Also throw in such physical factors as groove width (which is different for factory audio disks and CDR specs) and the literally microscopic accuracy of the manufacturing necessary to make a good consistent disk. Utter flatness and resistance to warping (unlike what we strive for in our lives) are needed. As a side note, some CDR manufacturers are replacing their stamper dyes (molds) almost every 4-6 months to keep up with the changing dye formulations.

So even a good old Tayo Yuden Cyanine CDR is not the same disk it was two years ago.

Oh yeah:

I strongly encourage you next time yer bored, to grab some coaster you made and break it. Go ahead, its good fun - it blows up with surprising force. *DO NOT LOOK!* - in fact close your eyes while you break it. Point it at a corner of the room or the pieces'll be all over the place.

Then find some shard that's scattered about and check it out. You'll find the actual micro-thin burning surface is in fact glued to the TOP of the disk, and the plastic underneath makes this surface flat, like pressing your face against a window. Sometimes there is writable paint on top of the reflective coat, obscuring but not protecting it.

From this you'll see just how obviously the most delicate part of a disk is actually the TOP of the disk, and you'll see how incredibly easy it is to instantly and permanently destroy a disk by scratching this layer. You will need to find a shard with a frayed bit of reflective layer to really see what I mean here.

Kodak Ultimas, Mitsuis, cdrecordable disks all have a protective coating on top for this. cdrecordable has confirmed they license their dyes from Mitsui by the way, so they have a firm stake as one of the cheapest sources of quality CDR's on the net.

Episode 2: The Depths and Depravity in Burning Plastic

Here's where it gets weird:

The pits in a factory pressed CD vary in length to denote information. Fine. But the length is *relative to time* - in other words to the rate of spin on the disk. This is bizzarre since they must remain readable within very tight (microscopic!) specs. Consequently we have long and short write strategy types to compensate for this, and associated media to make it all happen. Its chaos and deeply weird, but it works.

The whole idea is to imitate these microscopic varying-length pits made by CD presses as per Phillips's patent. Not a trivial undertaking when using a laser to burn dyes embedded in plastic travelling at high speeds - especially considering the margin for error and this wacky relative pit length scenario..

However, read on:

When actually creating a pit of a particular length, everything varies with the whim of the tree spirits. A certain setting on a laser of a certain strength that produces a certain length pit on one disk at such a spin rate will not necessarily produce the same length pit when a different dye is used, or the ambient temperature goes up, or the sun peeks out from behind the clouds in Tuktayuktuk for that matter...

Nothing is linear here either, and doubling the setting for a 3T pit does not produce a pit twice as long. Its insanely finnicky stuff to get right. Additionally, your burner is optimized for certain dye types and write strategies, which are themselves in a continuous state of flux.

Then of course the reader has to interpret these pits exactly in order to accurately reproduce the data contained within. Enter the mayhem of accurate ripping and the birth of such tools as EAC and cdparanoia to combat all this ambiguity, essentially by re-reading the data until its satisfied it statistically speaking has the correct bits...this is not trivial either, as is evidenced by some cheap readers not even being able to maintain a consistent offset, literally making it impossible to get accurate audio rips.

Another factor here is the relative reflectivity of the dyes used. If its brighter it requires more laser or more time to make a good impression, and still has to be read by the stereo CD player, which of course is built to read a certain relectivity at different specs than those called for in CDR technology.

So its entirely possible that your Phytloyanine disk burned with a long write strategy on your old burner with the weaker laser won't be playable on your stereo, but might be fine if burned at a slower speed on a full moon in May over a fine pint of Guinness.

As a side note, the various CDR identifiers out there of course can't actually tell what the dye on the disk is - only what the stamper that made the disk is designed to produce, and consequently enter into the pregroove's ATIP info.

That may well change with the new specs. The good news is that you can be sure that if it says Cyanine, it is Cyanine, since the differences between dyes is so pronounced that a you can't use a Phyalocyanine stamper to make a Cyanine disk (or visa versa). However, a stamper made for Cyanine type 1 might well be used to make a type 0 disk, or use a reformulation of the originally intended dye.

Episode 3: Gearhead Love

So what colour disk should I get for my burner then?

As you can see, there are no hard and fast answers to this. "Whatever works for you" is good advice. Older burners tend to be designed for a Cyanine long write strategy, and newer ones for Phytlocyanine short write strategies.

Or go with the highend manufacturers that are consistently on the cutting edge of this rapidly developing technology and have always out-performed mandatory specifications, like the famous Plextor/Mitsui combo.

Aw christ, why Plextor?

Basically they have been at the forefront of CDR technology since the beginning. Their drives are of universally high quality, and tend to not only define, but exceed standards imposed on CDR(OM) drives. It is not uncommon to have Plextors burning thousends upon thousends of disks correctly and without a complaint. Their ripping accuracy is similiarly without peer. They actually design their CDROM's with accurate audio extraction in mind.

Now immediately after saying this, you should know that shawn has burned thousends of disks spread over many years with a crappy old P133 laptop and an external USB 4x HP burner, about the most nightmarish setup going, so go figure. Mind you, the ol' beast refuses to extract audio accurately, so its a good thing he archives his shns.

Here's the scoop on what Plextor's up to right now. They invented BurnProof technology to prevent coasters caused by buffer underruns. Works beautifully. Essentially if your buffer runs out of data because you've got seventeen other apps open at the same time, (Plextors have nice big buffers too) then the laser stops at an ECC or header spot away from the data part of the disk and hangs out until it can continue burning. I can actually burn data images directly from drives located across a 100Mbit network connection using CDRDAO with BurnProof turned on as long as I don't bog down the network by streaming the latest shn seed from the server across the house at the same time..

Next up from Plextor:

PowerRec II - supposed to be a couple years off, but according to a Plextor beta tester *cough!*, they already have drives that can recognize the media type and calibrate themselves with respect to write speed, write strategy, and laser strength, integrated with BurnProof in order to provide the ideal burn. Other manufacturers like Yamaha are also working on this logical next step.

But THEN we have OPC. Get this..

What happens here is that the burner monitors the reflected light coming back from the disk as the burned pits form, comitting a signature to memory. As the burn progresses, the Plextors will monitor the new marks as they are created, and actually modify the burnspeed *on the fly!* to maintain the optimum burn. No kidding. The technology has to mature for a while before going public, but our friendly brotha at Plextor claims to be playing with pre-alpha firmware that already works. It could be that all you gotta do is upgrade yer current Plextor's firmware to get in on this good stuff when its ready..

So what's with the Mitsui trip then?

Mitsui directly controls every aspect of their production process. They do not outsource any part of the manufacturing process, technology, or even raw materials(!). Their quality control is second to none, and one of the key trips is to make CDR's as flat as possible to enable stability at high RPM's. That's kind of the main deal with 24x and now the Plextor-only 40x certification. Its also crucial for longevity, since a disk that is easily warped will also become unreadable very quickly.

The gold disks come with a lifetime guarantee. In all the industry testing for Orange Book compliance (involving block error rate (BER) tests on abused disks, Mitsui's consistently outperform the specs, in particular the light exposure tests. (CDR masters going in for mass production are made to Red Book specs by the way.) They also coat their disks with a protective layer to guard against scratching, including the top side of the disk.

They also own the patent on Phytlocyanine dye, which as I explained earlier is far superior to Cyanine/Azo dyes.

That said, they are the pinnacle of CDR's. They gained their reputation in the early stages and have held true. They now license their dyes to people like Kodak and cdrecordable, who make excellent disks themselves.

Update:

Unfortunately Kodak has now sold off their CDR assets, including Matsushita Manufacturing LLC of America at the end of last year. They made good stuff, get 'em while you can.

Episode 4: Let's take 'er for a spin then!

...and wrecklessly forge on to the software side of things..

When you are ripping audio disks, use EAC for windows or cdparanoia for *nix. Mac users have Trackthief. This software knows all about CDROM offsets, CDR sector boundaries, and so on. You will have to tell it manually what your drive's offset is. The resultant wavs will be as bit accurate as possible, and when burned back to disk will yield non-skipping, non-popping audio CD's if everything else is right.

Anything else will result in inaccurate rips, and you will be corrupting the community's gene pool, bringing disease and pestilence on the land. You can easily check your ripping by making an md5sum of some wavs, burning them to audio, then ripping them back to wav and checking the md5sum you made for the originals. If they fail you need to get your ripping trip together pronto or live with your own karma...or archive your shns!

EAC/cdparanoia will also tell you a little about your reader, because they require setting and checking your CDROM's offset and will give you a log file of the ripping process to let you know how many potential corrupted bits are in your wav files.

Of course shn files completely eliminate all the ripping ambiguity. Shn disks are burned as data CD's, and file integrity can be verified with an included md5sum, ensuring precise clones of the original master tapes. Places like etree.org archive the md5sums from the original seeds of shows, so you can check the lineage of your sources directly.

It might be worth archiving your shn files and burning audio disks as needed to throw in the truck, give to friends, etc. This way you maintain a perfect clone of the source recording for future audio burns, your next trade - and future generations if yer thinking of propagating the species with that special someone in yer life on a groovy afternoon on a sunny hillside..

Burning. Ouch. I must be out of my mind to even go here. Passions run high with this one, so please review the opening disclaimer before proceeding. There are lots of considerations to take into account here, including the robustness of the burning engine itself, supported drives, the ability to create bit-accurate data copies, conformity to standards and so on.

If you actually read all this drivel so far, you probably appreciate that the process of interfacing with the burning device to provide an accurate, steady bitstream to be burned into a disk is not quite so trivial as might appear. And I haven't even touched on file systems, sectors, EEC headers, zones, and all that dry technical grind that define the exact format of a CDR. Yech, don't ask.

For our purposes, the number one factor is the ability to burn in Disk-At-Once (DAO) mode. Anything else and yer playing with fire - especially that abomination called DirectCD that used to be bundled with burners. It uses a packet writing technique, and is to be treated as the very incarnation of evil itself and purged from your system accordingly. I'm serious, I've seen 70+ packet written CD's suddenly simply stop working all at once, representing a devastating loss of data to a friend of mine. He now believes in my DAO fetish.

Speaking of DAO, I'd say that any software that supports it (and you can dig out the place to make that your default setting) will do fine. If you're wondering, the absolute cadillac of burning apps for windows types is CDRWin. Rumoured to be based on opensource unix code, it makes good bit-accurate rips of data CD's into a format called bin/cue, and is very good at burning data reliably, bit by bit, onto a CD. All CD's rigorously conform to standards, with no convienience kludges to make it work. It supports BurnProof, raw read/writing, and ONLY does DAO writing. It doesn't even know what TAO, packet writing, or any of those other hokey methods are.

Unix users have CDRDAO for all that stuff. Needless to say it works perfectly out of the box, including BurnProof support, leaving them once again to wonder why people would even use an inferior OS. (Then casually engage them in a linux vs. BSD debate and watch the sparks fly..)

If you've been using Nero for audio:

PLEASE check out the integrity of your audio disks! A bug has been discovered wherein Nero consistently *loses frames of audio*, and writes corrupt tunes to disk! Ahead software has confirmed this, and pomises a fix sometime. This really hoses Nero users who burn audio disks and didn't archive their shns. One can only wonder how many shows out there have been affected by this rediculous bug. The original report is gone, but have a search of google to get an idea.

You can check your disks with md5sum as I described above, and shntool will give you sector boundarys and lenths of the wavs.

One sneaky little issue that has caused immense headaches for people is the cursed ASPI layer. This is a standard device interface layer that is owned by Adaptec. Huh? You heard me, a standard that is proprietrary. Sort of like the Cisco/VRRP debacle, but that's a different trip all together. The ASPI layer basically makes an ATAPI (IDE) device look like a SCSI device to the burning util in question. Only Adaptec products (like EZCD) are allowed to ship with an ASPI layer.

This causes mayhem in itself, with differing versions and other manufacturers making their own ASPI knockoffs. Adaptec has gone so far now as to make their installers check if you have an Adaptec product (hardware or software) installed before it will throw the thing in there. You must load an ASPI layer to burn disks if your app doesn't bring its own, which CDRWin now does.

As an aside, I hear some dilligent freedom hackers have modified this installer to load the ASPI layer regardless of such Adaptec created environmental concerns and released it on the 'net for public download. This will also install ASPI layers onto XP machines, which have their own issues regarding burning with their "integrated" burning facility junk. I also gather that you can goto your "Control Panel - Add/Remove Hardware" and pretend to install an Adaptec SCSI card to fool the official Adaptec ASPI installer.

Update: Adaptec received so much flak for this move that they have relented, and released the latest ASPI installer to load on non-Adaptec endowed PC's and it supports XP too.

So what can we conclude with all this? Its a crazy, fast-changing, dynamic little corner of technology, that's for sure. Are there any guaranteed solutions? No. But it does go some way towards explaining the rabid brand conciousness some people exhibit when confronted with this debate. You will have to experiment, try this and that, until you have a dependably working combination of ingredients.

I would say though, if you go Plextor+Mitsui+CDRWin and have a reasonably fast hard drive, you can't go wrong - and based on my experience, will never regret the reliable, consistent burns you will achieve for years to come. You will also have the comfort of knowing that people you trade with won't groan when they open their package to find badly burned cheapo CDR's that pop and click, wrecking their eagerly awaited can't-miss jam of the year.

Instead they'll throw the new disks on, crank it up, and invitingly start to slink about the kitchen in a suggestive manner as the groove begins to move their bones and everything erupts in titanic sexy mayhem, encouraging everyone to get on up, feel free, and groove!

Similar Threads
Thread	Forum	Replies	Last Post
HOW DO I ADD THE CHECKSUMS... - firemt66	Technobabble	2	2013-12-02 03:15 AM
Where to download checksums? - popeye	Technobabble	1	2006-12-03 11:24 AM
creating checksums - Music 2 My Ears	Technobabble	2	2006-07-05 12:24 AM
How do I get Checksums? - Scott	Technobabble	7	2005-09-09 04:54 PM