
This is an excerpt from the main AMPlay documentation (v2.03).

* 4.6 Database:
~~~~~~~~~~~~~~~

* 4.6.1 Naming:
~~~~~~~~~~~~~~~

Album-Track separator and Artist-Album separator:

This configures how AMPlay works out the Track, Album and Artist names
from the full filename for tracks that use pathname based naming. By
default both of these are dots, which would imply that the tracks are
in a subdirectory named after the album, and the albums are in
subdirectories named after the artist.

If you have a system where all the files are in one single directory,
but named something like Artist_-_Album_-_Track/mp3, then you should
change these to be _-_, or whatever naming system you use.

Name new tracks from:

This determines whether newly added tracks get their naming details
from the pathname, or whether the tag on the file should be read.

Default comment:

For tracks that use pathname based naming, the comment field is empty
(there is no way to pick the comment field out of the pathname). This
specifies the default comment that should be used for such tracks. Note
that it may contain macros.


* 4.6.2 Adding Tracks:
~~~~~~~~~~~~~~~~~~~~~~

Included Filetypes and Included Extensions:

This specifies what types to add to the database when scanning a
directory or adding a file. The file must match something in both
boxes in order to be included. The boxes should contain a comma
separated list, with no spaces. Filetypes should be specified in hex.
Start the file extension list with a comma to include files with no
extension.

If your MP3 collection is such that there are no consistent settings
for this then you can disable either of these options. However, if
you do disable them, be aware that non-MP3 files could end up in the
database, especially when scanning directories. AMPlay does not
examine the contents of files to determine whether they really are
MP3s.

These checks are carried out when dragging MP3 files or directories
onto AMPlay, and do not apply to loading playlists. Handling double
clicked files will only ever respond to filetype &1ad, but is
subject to the extension check.


Scan subdirectories to a depth of:

Fairly self explanatory - if on, when you drag a directory onto
AMPlay, it will walk the whole directory structure looking for
matching files. Otherwise only the files in that directory itself
will be looked at.

The subdirectory depth option allows you to configure how deep down
the directory structure to go. A value of 0 is a special case, and
tells it to scan all the way down. 1 is just the directory that was
dragged (i.e. same as with scan subdirectories turned off), 2 is that
plus subdirectories etc.


* 4.6.3 Database options:
~~~~~~~~~~~~~~~~~~~~~~~~~

Default Directory:

This allows you to tell AMPlay where all or most of your MP3s are. This
has no effect on where you can or can't store your MP3s, but does allow
AMPlay to store the path to each file more efficiently. You can drag a
directory onto this icon to set it.

Note that changing this option may cause quite a lot of recalculation
work within AMPlay as it reconstructs the paths for tracks using the
old default directory, and works out which tracks are in the new one.

Uniqueness:

This tells AMPlay how far back in the track history to look when
checking whether something has already been played recently. i.e. it
defines what 'recently' means in that context. It is a percentage of
the tracks available to AMPlay at the time. e.g. if there are 1000
tracks in the database, 100 of which pass the current filter settings,
then if uniqueness is 75%, it will look back through the most recent 75
history entries.

Although it is a percentage, values above 90% are not allowed. This is
because very high uniqueness values, together with large numbers of
available tracks and a large history can lead AMPlay into what I call
the needle in the haystack problem - This is where most of the things
it can pick have to get discarded as having been played too recently.

Dynamic Area limit:

This defines how much address space AMPlay reserves for the database on
startup. It does not claim this much memory, but tells RISC OS that its
dynamic area will not grow beyond this limit.

The default is 32MB which should be plenty for most purposes. (A
database of 100,000 tracks produces a 14MB database, and peaks at 25MB
used while adding the tracks). If you have very large numbers of
tracks, each with a long pathname and using tags (or editted
pathnames), then you might need to raise this.

AMPlay needs to be restarted for this change to take effect.


Sync maximum history with total tracks / Maximum history:

The database tables for tracks, albums, artists etc have clearly
defined limits. They are as big as they need to be to hold the
information about the number of tracks you have.

History is different in that it can just grow indefinitely. Even if you
only have a very small number of tracks, there is no logical limit to
how many history entries you could generate.

So, there needs to be some sort of cap on the history to stop it eating
the entire database eventually. The default setting is to keep a number
of history entries roughly equal to the total number of tracks in the
database. As more tracks are added, the allowed length of the history
grows accordingly. When the maximum history is reached, new items added
to it will cause the oldest items to be removed.

Alternatively, you can set your own fixed upper limit.

________________________________________________________________________
Copyright  2008 Mike Sandells, mike@mikejs.com
Last Modified: 30.05.2008