home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
ARM Club 3
/
TheARMClub_PDCD3.iso
/
hensa
/
misc
/
tapefit_1
/
!TapeFit
/
!Help
next >
Wrap
Text File
|
1996-02-25
|
14KB
|
253 lines
******** ********
** **
** ** ** **
** ** ** **
** ** **
** ***** ** *** **** ** **** ******
** ** ** *** ** ** ** ****** ** **
** ** ** ** ** ** ** ** **
** ******* ** ** ******** ** ** **
** ** ** ** ** ** ** ** **
** ** ** ** ** ** ** ** **
** ** ** *** ** ** ** ** ** ** **
** ***** * ** *** ***** ** ******** ****
** +---------------------------------+
** | Version 0.03/1.21 (24 Feb 1996) |
** | © Musus Umbra, 1996. |
** +---------------------------------+
What is it ?
~~~~~~~~~~~~
Tapefit is a simple(ish) utility that attempts to find the best possible
arrangement of a given set of tracks on a cassette of a given length. It
will try to make both sides as full as possible, but leave the end of side 2
blank if there are insufficient tracks to fill the whole tape. If there are
more tracks than will fit, the best fitting ones will be chosen.
How to Use it
~~~~~~~~~~~~~
First of all, choose the tracks you want to put a tape together from.
Create a text file (using !Edit, !StrongEd, !Zap, or whatever) that lists
the tracks in the following fashion:
mm:ss <trackname>
...
Where mm:ss is the length of the track (minutes:seconds). You can put any
whitespace between the time and the track name except a newline. So, for
instance, tabs are fine, as are spaces. Blank lines and lines that start
with the character '#' are ignored. See the supplied track file 'x' for
an example. Now, double click on !TapeFit in a filer window to run TapeFit.
When tapefit is loaded, clicking on its icon with Select will open a
window. This window allows you to control the input/output and the more
advanced options of tapefit. If you drag a textfile to this window, it
will be selected as the 'input' for tapefit. Drag your file of the tracks
you want into this window - you'll see the icons change and the filename
of your file appear in the 'Input' section of the window.
You're ready to set the advanced options now, these are controlled by
the section labelled 'Options'. A detailed discussion of the options can
be found below. For the moment, just leave them as they are.
TapeFit can either print its output on the screen (in a taskwindow), or
save it to a file (so you can print it, etc). If you want the output in a
taskwindow, make sure than 'Screen' is selected in the 'Output' section. If
you want the output in a file, select 'File' and either enter a filename, or
click on the 'pop up menu' button and drag the textfile icon to a filer
window after altering the name in the 'Save As' box that appears. If you
select the 'Auto Run' option button, the file will be loaded into your text
editor when it is complete.
All that's left to do now is to tell TapeFit what size of tape you want
the tracks fitting to. Do this with the 'Tape' section.
Okay, you've set the input and output, so now you can run TapeFit. Click
on the 'Go' button and TapeFit will spring into life. If you set the output
to be 'Screen', a taskwindow will appear and TapeFit will print the results
in it (along with messages saying how far it's got with the fitting). If you
chose 'File', the hourglass will come on, and TapeFit will write its results
to the file you specified. When the hourglass turns off, your file is ready.
If you chose 'Auto Run', the file will be loaded into your text editor).
Advanced Options
~~~~~~~~~~~~~~~~
Tolerance
---------
When fitting tracks to a tape, TapeFit can allow some 'leeway' at the
end of a side. This allows tapefit to accept an 'acceptable' solution,
rather than plodding on and on looking for a better one. The 'leeway'
is controlled by the 'Tolerance' option. Tolerance is specified in seconds
and is the largest gap you're prepared to accept at the end of a side.
The default value is 30 seconds, but any (reasonable) value can be used.
Even low values (5-10) are sufficient to allow TapeFit to find a solution
faster than with no tolerance.
Intertrack Gaps
---------------
When you put together a tape, you'll probably want to leave a gap of,
say, 3 or 4 seconds between the tracks. TapeFit can take this extra gap
into account when fitting the tracks to the tape. The gap time is added
to the playing time of all but the last track on a side for the purposes
of finding a solution. For all this option is theoretically very useful,
often the playing time for a track on a CD (or whatever) includes a couple
of seconds silence either at the start or the end (or both). In effect,
this is the intertrack gap. TapeFit includes this option for completenes,
and in case anybody wishes to have largish (>5secs) gaps. The gaps are
set up using the 'Leave nn s between' section of the 'Options' section.
(See also the note on tape lengths).
Shuffling
---------
Often, when you list the tracks for a compilation, you'll end up with
a lot of tracks by the same artist side by side in the track list. Due to
the way it works, TapeFit will tend to keep these tracks clustered together
in the solution. This probably isn't what you want. Therefore, TapeFit
can be made to shuffle the track list before finding a solution. This has
another distinct advantage - it allows tapefit to produce different results
for the same input on different runs (this happens because the shuffling
method is non-deterministic). This means that you can re-run TapeFit if,
for instance, you don't like the solution generated. Conversely, if you're
fitting a long album onto a tape, you'll probably want to turn shuffling
off - this will make tapefit try to keep the tracks in order.
A good value for the number of shuffles is > 10 * the number of tracks.
Shuffling is quite fast, so it's okay to use a big (>1000) value.
Performance Issues
~~~~~~~~~~~~~~~~~~
Performance will be poor if there are lots of short tracks. The example
file 'x2' is a case in point. This is because TapeFit exhaustively tests
every possible arrangement of tracks until it finds one that satisfies the
tolerance specified (or runs out of variations). With lots of short tracks,
this means a *lot* of work before a good solution can be found.
On machines with ARM250 or better processors, performance should be
adequate. Performance is acceptable on my ARM3 A3000, and should be good
on a RiscPC. "Cheap / Fast / Good. Pick any two."
I've done a few speed trials, and here are the results:
Output to File Output to Taskwindow
No Cache Cache No Cache Cache
1: 2 <1 8 3
2: 7 <2 15 4
3: 52 12 54 15
3: 75 17 117 20
5: 78 18 123 22
All times are in seconds. No shuffling or intertrack gaps were used.
Test 1 was input 'x', tolerance 15
Test 2 was input 'x', tolerance 0
Test 3 was input 'x2', tolerance 60
Test 4 was input 'x2', tolerance 15
Test 5 was input 'x2', tolerance 5
Note that shuffling can affect these times either way, for instance,
Test 2 with shuffling (cache on) was about 3 times as fast, whereas Test 4
with shuffling (cache on) was anywhere up to 8 times slower.
In general, a high tolerance will speed up fitting of even the most
awkward tracks.
Notes
~~~~~
When typing input from the keyboard (I don't expect anyoen will ever use
this, it's included for completeness and so I could test TapeFit easily), a
'.' on a line by itself will terminate input. The same is true of a file,
so if you put a line with just the '.' at the start somewhere in your file,
then TapeFit will ignore everything from there on. This can be useful - you
can make a file with many tracks in, your favourites at the top, and then
move a '.' down the file until TapeFit gets a solution you like.
Performance is best with many tracks of reasonable length. Conversely,
with lots of short tracks (see example file 'x2'), performance is poor.
TapeFit is still usable for such sets of tracks, but be prepared to wait a
minute or so. In these cases, a tolerance of >10 seconds can really help
the fitting process.
Nothing says that you have to record the tracks in the order that TapeFit
has generated them. Since it's the total time of the tracks on a side that
matters, feel free to jiggle them around within a side.
Tape sizes can vary considerably between manufacturers. For instance,
some BASF C90s I was using recently weighed in at well over 48 minutes a
side. However, the Maxell C90s that I used next were only about 46 minutes
a side. In general, most tapes will be at least about a minute longer than
the stated length. You can set TapeFit to use these longer times by entering
the 'true' tape size in the 'Tape' section (or click on one of the presets
and then use the arrow icons). It's a good idea to keep track of how long
different makes & models of cassette are, so that you can use TapeFit to the
best advantage.
If you've taken a look at the example track file you'll have noticed that
there's far more there than will fit on a C90. In fact, there's enough
tracks there to fill 3 C90s and still have half an hour of music left. This
is because I wanted to do a multi-tape compilation. I simply ran TapeFit on
the large file, cut the 'Tracks not Fitted' section out of the output file
and ran TapeFit on this, ... In this way, you can use multiple tapes.
If you can, it's best to give tapefit more tracks than will fit on a tape
as this allows greater flexibility when fitting to a cassette, and means
that you're more likely to get a good result.
It's probably best to try a fitting with the output set to 'Screen' at
first, just to see how long TapeFit will take. Fitting is usually fast,
but for some input, make take some time.
TapeFit is actually a command line program that is presented here with
a Desktop front end. All the front end does is to put together the command
line necessary to run tapefit, and then either simply runs the main program,
or starts a taskwindow to run the program in. If you look inside the
!TapeFit application (shift double click on it), you'll see the main
program (tapefit), and a file 'CLusage' (and the source code in the
directory 'c'). The file 'CLusage' gives information on how to use TapeFit
from the command line, and notes on porting the program to other
environments.
Background
~~~~~~~~~~
TapeFit was written becuase I wanted to put together a set of tapes with
some of my favourite music on. Having done this in the past by 'trial and
error' (frequently having to hunt around for a track less than some length
in order to completely fill a side, having just had the track I wanted cut
off at the end of the tape), I decided that it was time to get sophisticated
about the whole thing. Therefore, I knocked up a file of all the tracks
I'd consider for my collection, and sat down to ponder the question of how
to go about finding an optimal solution. After a little playing, I came
up with an algorithm that was guaranteed to generate the best possible
arrangement of the tracks on a tape. Great, I thought. Then I tried it
with my file. Oh oh. I never found out whether it gave the perfect
answer since it took so long I aborted it. Looking closer, I noticed
that my beautiful algorithm was O(3^N) [it took a time proportional to
3 to the power of the number of tracks]. Clearly this was no good. So,
I set about adding heuristics in the most used sections of code, and the
result is the stupendously faster TapeFit that we have today.
Next I wrote the front end (please forgive the code, it's a drastically
cut down version of my generic (and naff) BASIC Wimp task). Over the
next few days, the front end had more bells and whistles added, and unless
TapeFit sprouts new options, will probably stay as it is in future.
Disclaimer & Licence
~~~~~~~~~~~~~~~~~~~~
Use of this software is completely at your own risk. The author can accept no
responsibility for any damage/loss arising from the use, or inability to use
this software. No warranty, express or implied, applies to this software.
This is not PD: the Copyright in this software belongs at all times to the
author. However, permission is granted for unrestricted distribution
prodividing that *no* charge is made for the distribution [a charge may be made
for handling/media] and that the whole of the software is supplied intact and
unaltered. Permission is also granted for unrestricted use and alteration of
the software [but if you fix a bug / add anything nice, let me know so I can
patch the 'master' version].
Bug reports / comments / etc to:
Andy Holdsworth c/o 23 Baronsway, Whitkirk, Leeds, LS15 7AW, England.
(until Sept-ish '96: A.J.Holdsworth@ncl.ac.uk)