* 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 key modifier) 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 key modifier) 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 .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