
* 6. Frequently Asked Questions:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Some of these are frequently asked, some are pre-emptively
answered...

________________________________________________________________________


* 6.1 What is the position with AMPlay and RISC OS 5?:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

A. AMPlay 2 is 26/32 bit neutral, and should work on versions of
   RISC OS from 3.7 to 5.x (although it has only been tested on 4.27
   and 5.11).

________________________________________________________________________


* 6.2 Why is pathname based naming the default?:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

A. Several reasons. Using the MP3 ID Tag to work out the album and
   artist name for the tracks has many drawbacks, and is generally
   harder to set up to give good results. In approximate order of
   magnitude, the reasons for not using tags by default are;

   - In order to work effectively, all tracks must not just be tagged,
     but must be tagged consistently. Some artists are not consistent
     in the spelling of their artist name (e.g. Offspring,
     The Offspring, Frontline Assembly, Front Line Assembly), and if the
     tracks are tagged exactly as the name appears on the album, then
     they will appear as different artist names to AMPlay. Similarly,
     if one tag has spaces in the name, and another has hard spaces,
     again this will be treated as a difference, and an artist or album
     boundary will result. AMPlay has options that work around this by
     allowing the boundary check to be case insensitive, removing
     spaces before comparison, or ignoring a leading "The ". Such
     processes work, but slow down the boundary scanning and sorting
     process.

     This wouldn't matter if the tag was purely being used to display
     currently playing track information (e.g. as it is in a portable
     MP3 player), but AMPlay needs to collate the information from
     many tracks, and various features depend on this information
     being accurate.

   - Length of time taken to go through all the tracks, and read the
     tag information in the first place. For large numbers of tracks,
     this is non-trivial.

   - Even if the tracks are tagged, most people store their MP3s in
     some sort of heirarchical structure in any case, in order to be
     able to find them. If AMPlay uses that same structure, then the
     way in which you find the files you want to play is the same as it
     would be in the filer.

   - Increased memory usage by AMPlay, and slower start times (due to
     loading the cached tag information).

   - You can't look at a file, and know immediately what AMPlay will do
     with it. To work it out, you have to look at the contents of the
     file. With pathnames, the names are obvious.

   - The tag is limited to 30 characters for the track, album and
     artist names. In many cases this is insufficient, and leads to
     truncation. These can be corrected once within AMPlay, but the
     pathname based name has much greater scope (256 chars for the
     entire thing, in theory, somewhat less in practice). v2 of the
     tag format supports larger strings, but reading these tags is
     a rather difficult proposition, especially in bulk. Nor does v2
     solve the other issues listed above.

   Don't get me wrong here - ID tags are a very good thing, but they
   work best in the situation where you want to know information about
   the currently playing track (this is always available in AMPlay,
   irrespective of the default naming options). Where tags are less
   useful, in my opinion, is the situation where you want to collate
   information about a large number of tracks.

   Obviously, if your tracks are all already tagged in a consistent
   manner, and the path to the file doesn't contain the artist and
   album name, then you may well want to use this.

   You may also want to turn tag based naming on for those tracks that
   exist outside of whatever filesystem hierarchy you store your tracks
   in.

________________________________________________________________________


* 6.3 How can I improve the speed at which track info is read?:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

A. For some operations, AMPlay is relying on the AMPlayer module to
   perform particular operations. When adding tracks in bulk (e.g.
   when scanning a large directory structure with 1000's of tracks),
   AMPlayer's defaults get in the way a bit, and don't offer best
   performance.

   The issue here is the AMPlayer filebuffer. You should refer to the
   AMPlayer documentation for more information on this, but my
   understanding of it is that the module will read the amount of data
   specified by the size of the AMPlayer$filebuffer variable when it
   accesses a file, including access to read the duration. On my
   machine, running the unofficial 32-bit build, the default value of
   this appears to be 128KB.

   This means that attempts to read the track duration (which
   potentially only needs to read the track header) ends up fetching
   the first 128KB of the file. Reading tag data is also slowed by this.

   While the filebuffer is beneficial in reducing load and avoiding
   track skipping while playing a track, it actually slows down the
   process of reading information about a large number of files.

   To fix this temporarily (e.g. prior to a bulk track import), open
   a taskwindow (CTRL+F12) and;

   - Type;

     show AMPlayer$filebuffer

     and note down the value (if any). Then type

     set AMPlayer$filebuffer 0

   - Import the tracks.

   - Once done, click in the taskwindow again, and type;

     set AMPlayer$filebuffer (value previously noted)

     Or, if there was no value set before;

     unset AMPlayer$filebuffer

     then close the task window.

   You should only need to do this before adding a large number of
   tracks to the database. During normal playback, the filebuffer is
   beneficial.

   Note that the filebuffer variable is nothing to do with the AMPlayer
   buffer size in the options. That affects the AMPlayer$buffer$
   variable, which is the buffer for decoded audio as it is played
   back, while the filebuffer is for buffering the undecoded mp3 data
   before the module decodes it.

   Some rough benchmarking, on an Iyonix, with 1000 MP3s in a test
   directory (structured as test.artist.album.tracks/mp3):

   Filebuffer    Naming default    Time (sec)    Time/track (cs)
     0           Pathname           23            2.3
   128           Pathname           52            5.2
     0           Tag                42            4.2
   128           Tag               154           15.4

   From which we can see that turning the filebuffer off during a large
   import is beneficial, and this is by a much larger margin when tag
   based naming is the default. With it off, using tag based naming
   doesn't slow the process down that much.

   Note that this test was with the files on the local hard disk. If
   a network filesystem is involved then I expect the slowdown would be
   much more noticeable (the extra 128KB would take a lot longer to
   read.)

   Changing the buffer will not affect the speed of writing tags,
   because AMPlay does this itself, rather than relying on AMPlayer.

________________________________________________________________________


* 6.4 Why are some tracks listed as 0 seconds?:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

A. This probably means that the files have a corrupt mp3 header. This
   prevents AMPlayer from extracting the duration successfully (using
   the AMInfo command on the file will also report errors). The fix for
   this is to play the tracks - the duration is always reported
   correctly during playback, and if this differs from the cached
   duration, AMPlay will update its cache with the new information. You
   don't need to play the entire track, just enough of it for the
   duration to appear correctly on the main window.

   Currently, such tracks will end up with a duration of 0 again if you
   use the 'refresh times' option on them as this clears the existing
   duration and then does the equivalent of aminfo to get the time.

________________________________________________________________________


* 6.5 Why is relative track volume not proportional?:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

A. Because it was simpler to implement. If I think there is a need for
   a percentage increase instead of an offset, I may add this as an
   option. It does however complicate things because percentages mean
   non-integer answers and rounding errors and things like that, which
   gets messy if other front ends are also altering the effective
   volume.

   Suppose player volume is 40, and track volume was +15%. This would
   give an effective volume of 46. Another front end then increases the
   volume to 50. What should the player volume be as a result? 43 is
   the closest, but if we set the player volume to 43 and calculate the
   effective volume based on +15%, we would get 49, not 50
   (43*1.15=49.45, 44*1.15=50.6). Should AMPlay cope with the inaccuracy
   or tweak the effective volume down to 49, overriding the other front
   end?

   Integer offsets make life a lot simpler.

________________________________________________________________________


* 6.6 Why is AMPlay so big?:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~

A. Because it is.

   Basic playback is fairly simple to implement - the bulk of the code
   relates to the database of tracks and other information that
   AMPlay stores (including the code to add/remove/move/modify items
   within that database)

   The next biggest chunk is the code dealing with the database editor
   interface itself.

   The single biggest function is the macro expander, by quite a long
   way.

   As for the memory requirements, I think it keeps it down to a fairly
   reasonable level. In my case it works out to around 160 bytes per
   track, including the path to the file.

   (Note - AMPlay is supplied compiled, because this gives the best
   performance. However it is written entirely in BASIC, so a crunched
   version is also possible. The source download contains instructions
   for doing this. While the crunched version is a bit slower, it is
   also quite a bit smaller, so if memory use is an issue for you, you
   may wish to look into making a crunched version. Note that the
   crunched version just makes the program smaller - the database size
   would be unaffected.)

________________________________________________________________________


* 6.7 Why so many file formats?:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

A. The various file formats are indeed extremely similar, and I may
   add an annotated playlist format at some point, but the separate
   formats for the different categories of information will probably
   remain. The reason is that you might still want to have a file that
   contains nothing but the filter settings, or nothing but the linkage
   etc. It means that the files are smaller and quicker to import to an
   existing set up. The playlist file will always contain all files,
   even if their filter, linkage and volume settings are still default.

________________________________________________________________________


* 6.8 Why doesn't the saved state use the normal file formats?:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

A. Because the requirements are different. Speed of saving and speed of
   loading are significant, as is the fact that the state has more
   information that it needs to store (cached information about track
   names, durations etc). The saved file formats can't assume that the
   track numbers are the same as they were when they were saved, while
   the state files can assume this, and just use track numbers within
   the tracks array rather than specifying the path to the file to
   identify tracks.

________________________________________________________________________


* 6.9 Why can I not move tracks outside their album etc?:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

A. Because there is no interface for creating your own album and artist
   boundaries manually. Even if you could, many operations will refresh
   the boundaries implicitly, scrapping any that already exist and
   calculating where they should go based on the album and artist names
   that can be calculated for each track. This would have the effect of
   merging any splits that had been created.

   If you want to do this, then the easiest way is to edit the naming
   details of the tracks in question, and alter their album name, and/or
   their artist name. AMPlay will then declare a boundary and allow you
   to move them.

________________________________________________________________________


* 6.10 Why must tracks be adjacent to appear in the same album?:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

A. This is due to the way the information is stored internally.

   An album is an item in the database with attributes of first and
   last track. These attributes are pointers to the tracks database,
   and define where that album starts and ends.

   Throughout AMPlay is the assumption that an album is a contiguous
   block of tracks, and that an artist is a contiguous block of albums,
   and therefore also a contiguous block of tracks.

   This could be resolved by changing the album and artist arrays to
   store a list of all track numbers that they contain rather than just
   the first and last. This might happen eventually, but isn't planned
   soon.
   
________________________________________________________________________


* 6.11 Can I rename artists, albums or tracks?:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

A. Yes, see the section on the naming editor.

   The one thing you can't do currently is edit a pathname based name
   and then have AMPlay rename the file to suit the new name.

________________________________________________________________________


* 6.12 Why is zero-padding inconsistent on some menus?:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

A. This can happen if you have a menu that includes tracks from
   multiple albums, where some of those albums have 10 or more tracks,
   and some do not. The macro expander pads things to what it thinks is
   the maximim value for that field, unless you tell it not to pad
   things at all. If it's asked to expand the track number within the
   album, it does so, and pads it if there are 10 or more tracks, and
   doesn't if there aren't.

   This works fine in the case where all tracks in the menu come from
   the same album, because the padding is consistent. Where we have a
   mixture of tracks, it isn't entirely valid. What should happen is
   that the expander should take into account the fact that there are
   multiple albums involved, and pad if _any_ of those albums contains
   10 or more tracks.

   This is unlikely to get fixed, but a future version of AMPlay may
   offer more control over the padding, such as by forcing a particular
   value rather than relying on AMPlay's estimation of what the maximum
   value is.

________________________________________________________________________


* 6.13 Where did all the keyboard shortcuts go?:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

A. Keyboard shortcuts were something that I got effectively "for free"
   when AMPlay was written in WimpBASIC. Having re-implemented it in
   DrWimp, they are no longer free but require quite a bit of code.

   Keyboard shortcuts are on the to-do list, and should re-appear in
   later versions, probably properly configurable with a keymap file to
   allow you to specify your own keybindings.

   Meanwhile, use the application launcher tool of your choice to bind
   particular AMPlayCmd commands to particular keypresses, and you'll be
   fairly close.

________________________________________________________________________


* 6.14 What are all the adjust-click actions?:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

A. These are all documented in their relevant sections, but it can be
   handy to have a list of all the things you can do with the adjust
   button.

   Note that some of this behaviour is configurable.

   Main Window:

   - Adjust-click Play: Restart current track (and unpause if paused).

   - Adjust-click previous track,album,artist: previous item in
     database (select would be previous item in history).

   - Adjust-click next track,album,artist:  Next item in database
     (select would be next item in history or next item picked by
     current playback order if there were no more history items).

   - Adjust-click Next: Next item, picked by current playback order,
     regardless of current position in history. 

   - Adjust-click rewind or fast forward: Move by 1% of track length
     (Select moves by 10% of track length).

   - Adjust-click Database Editor button: Open Database Editor with
     the currently playing track selected (Or move to the currently
     playing track if the window is already open).

   - Adjust-click Currently Playing button: Open Database Editor with
     the Database Statistics pane selected.

   - Adjust-click actions for custom buttons are configurable.

   - Adjust-click Filters button: Open Filter Editor (Select gives a
     menu of currently active filters)

   - Adjust-click Search button: Open search window with options set
     to quickly go to another item of the same type as the current
     selection level (see section 3.2.2).

   - Adjust-close main window: Quit application.

   Goto Menu:

   - Adjust-click entry: Add item to history, and optionally move
     the history position to just prior to the newly added item.
     (depending on Shift keymodifier)
      
   History Menus:     

   - Adjust-click entry: Either move the current history position
     to just before the clicked item, or remove the clicked item
     from the history. (depending on Shift keymodifier)

   Iconbar Icon:

   - Configurable.


   Info Window:

   - Adjust-click mail/web buttons: Send URL to the keyboard buffer
     instead of launching it.
   

   Where items exist both as buttons and as menu items in the main menu
   structure, you can usually use adjust in the same way in the menu as
   you could on the button.

________________________________________________________________________


* 6.15 How do I clear the database and start again?:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

A. AMPlay versions prior to 2.00 didn't save the state if there was
   nothing in it. This meant that if you removed everything, and quit,
   it would all come back again when you restarted.

   AMPlay 2.00 and later handle this correctly - a saved state that
   contains no tracks is now possible.

   To clear the database and start again, simply open the database
   editor, select All Artists from the artists menu, thereby selecting
   the entire database, and click Remove. AMPlay will ask for
   confirmation that you really do want to do this.

   An alternative, if slightly more drastic, solution is to rename the
   directory containing the state files. This is in
   <Choices$dir>.Audio.MP3.AMPlay2.db_[ver], where [ver] is the database
   format version, currently 200.

________________________________________________________________________


* 6.16 What happens if the AMPlay and AMPlayCfg versions differ?:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

A. Generally, not much will go wrong. AMPlayCfg will preserve any
   comments or options that it doesn't recognise in the options and
   state files. However, there can be an issue with the skin settings.
   Specifically, AMPlayCfg looks at the skins directory to build a list
   of available skins for the pop-up menu. However, it decides what
   skins are available with reference to its own criteria for what skin
   versions are 'good'. If AMPlay is newer, the skins supplied with it
   may be too new for an older AMPlayCfg to recognise as good, and you
   may get an error that the skins settings are being reset to their
   default. This error will recur every time the options file is loaded
   or saved, because in that case the default skin itself is considered
   faulty.

   Conversely, using an AMPlayCfg version that is too new may let you
   pick a skin that is not actually supported by the AMPlay version you
   are running (it will silently revert to its internal default).

   The above problems can be avoided simply by ensuring that whenever
   you install or upgrade AMPlay, and a copy of AMPlayCfg is supplied
   with it, you install or upgrade that too.

________________________________________________________________________


* 6.17 Can I control AMPlay from the command line, or an obey file?:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

A. Yes. Refer to section 8.3 on AMPlayCmd. This allows AMPlay to be
   controlled (up to a point) from the command line, obey file,
   taskwindow etc.

________________________________________________________________________


* 6.18 How scalable is AMPlay?:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

A. There used to be a long waffly answer here that dealt with the
   theory. However, as part of testing 2.02, I thought I'd test it in
   practice. I've taken it up to 100,000 without any serious problems,
   and was pleasantly surprised at how well it performs at this level.

   With a database of 100,000 tracks, the size of the database on disk
   was 12MB, and in memory it was 14MB. During the addition of the
   tracks, memory usage peaked at 25MB.

   Performance was better than expected. Some benchmark figures from
   this database, on an Iyonix:

   Startup time (ramdisk off)             12.2 secs
   Startup time (ramdisk on)               9.6 secs
   Name refresh                           12.9 secs
   Boundary refresh                        6.8 secs
   Sort                                   67.1 secs
   Dbstats                                 1.2 secs
   Export                                  6.6 secs
   Search                                 17.4 secs
   Open history menu                       0.4 secs
   Complete state save (ramdisk off)      19.8 secs
   Complete state save (ramdisk on)        6.9 secs
   'Normal' state save (ramdisk off)       0.6 secs
   'Normal' state save (ramdisk on)        0.6 secs

   As you can see, there are some options which take a noticeable
   amount of time, but nothing too excessive. The time-consuming
   things are infrequent operations.

   If using a database of this size, you'd probably want to set the
   options for best performance, which would probably be:

   - Set boundary checking/sorting to case sensitive, space sensitive,
     and unset the 'ignore "the"' option. Sort raw.
   - Do not reverse the history menu.
   - Drop the uniqueness level to, say, 50%. (Alternatively, hardcode
     the maximum history entries to, say, 50,000 or less.)
   - Turn the 'use ramdisk on state save' option on. (You can see the
     benefits in the timings above - it is of less benefit for smaller
     databases.)
   - Use pathname based naming where possible.

   Rough rules for scaling;

   I find 150 bytes per track to be a useful guide, if using pathname
   based naming. For tag based naming, it's probably safe to double
   that. The tables in memory are created with some room for expansion
   built-in.
   
   The largest block in memory corresponds to the trackdb file on disk
   (pathdb is bigger on disk, but is many small blocks once loaded).
   This is typically 40% of the database, or a little less.

   The database in memory needs to have enough free space for the
   largest block to be resizeable, if needed by creating a new block of
   the required size afresh, before the old block is freed. Doing a
   database sort needs to do this. Therefore, from startup, the
   database should not be more than 60% used.

   The default settings place an upper limit on the dynamic area used
   for the database, of 32MB. My testing up to 100,000 peaked at 25MB,
   so there is some scope to go further with the default settings, but
   not a great deal. However, you can increase the dynamic area limit
   up to 256MB if needed, and if you have enough RAM in your machine.
   That would be enough for a database with around 1.2 million tracks.

________________________________________________________________________


* 6.19 What do the things in []s mean on the program info window?:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

A. The program information window reports quite a lot of information,
   much of it hopefully self explanatory. The AMPlay version information
   can have some extra pieces of information at the end, which have the
   following meanings;

   [alpha] - indicates an alpha version.
   [beta] - indicates a beta version.
   [custom] - indicates that it is a customised version (see license)
   [c] - indicates that AMPlay has been compiled.
   [i] - indicates that AMPlay is being interpreted.

   There is no indication to distinguish between verbose and crunched
   interpreted code.

________________________________________________________________________


* 6.20 Can the custom buttons perform 'internal' actions?:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

A. The custom buttons on the main window can only be told to do one
   of the following;

   - Run specified applications.
   - Open specified directories.
   - Issue specified *commands.

   There is no facility for them to hook in to internal functions to,
   e.g. open the export window.
   
   However, you can make use of the *command ability, and issue an
   AMPlayCMD command. This opens the custom buttons up to do anything
   that the AMPlay API has a command for. See section 7 for more on
   this.

   Remember that the select and adjust click actions can be different,
   but must be of the same type (i.e. they must both be apps, dirs, or
   commands).

________________________________________________________________________


* 6.21 What's going on with track numbering?:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

A. Firstly, a summary of the problem.

   When the pathname of a mp3 is decided, the most common format is;

   ArtistName.AlbumName.TrackNumber - TrackName/mp3

   i.e. The leafname of the file includes both the 'name' (song title
   or similar), and the number of the track within the album.

   Tags however have separate fields for the name and number of the
   track.

   Therefore, naming details derived from pathnames tend to have the
   number (and the ' - ') prefixed to the track name, while tag derived
   ones do not.

   The X modifier exists as one solution to this - it tries to extract
   just the name from a string that contains both name and number with
   some sort of separator sequence between them.

   This is all fine as far as it goes, but it gets messy when you have
   an album that contains some items using pathname and some using tag
   based naming.

   When AMPlay is performing a sort (by name), it includes the track
   number within album as part of the temporary string it constructs for
   sorting purposes. This string comprises;

   [artist name][album name][track number][track name]

   If all the tracks within an album use tag based names, and the track
   number was valid in the tag, then the album will come out correctly
   sorted regardless of whether the tracks have a leading number as part
   of their name.

   However, for pathname based names, the track number within album
   attribute is calculated on the fly from their current position within
   the album. If this was used in the sort, the current position of each
   track within the album would be preserved, regardless of whether it
   was correct.

   So, when sorting, the string is constructed as above, but the
   function that returns the track number within the album returns;

   - The track number, if the track uses tag based naming, or a manually
     editted pathname based name. i.e. if the source of the track
     number is external to amplay or has been confirmed by the user.
   - '00', if the track uses an uneditted pathname based name. i.e. if
     the track number is something that merely reflects the current
     position in the database.

   (This only applies during a sort. At all other times, the function
   always returns the track number within album)

   This should mean that the sorting of tracks within albums comes out
   correctly.

   It is still the case that a mixture of tag / editted pathname based
   tracks and uneditted pathname based tracks in the same album may come
   out with an odd sort order, but this can be rectified by editting
   the pathname based ones (and the tag based ones if needed) to produce
   the order you want.
   
________________________________________________________________________
Copyright  2008 Mike Sandells, mike@mikejs.com
Last Modified: 30.05.2008