| % $Id$ % |
| \appendix |
| |
| \input{appendix/file_formats.tex} |
| |
| \opt{lcd_bitmap}{\input{appendix/album_art_info.tex}} |
| |
| \input{appendix/wps_tags.tex} |
| |
| \input{appendix/config_file_options.tex} |
| |
| \input{appendix/menu_structure.tex} |
| |
| \chapter{User feedback}\label{sec:feedback} |
| \section{Bug reports} |
| If you experience inappropriate performance from any supported feature, |
| please file a bug report on our web page. Do not report missing |
| features as bugs, instead file them as feature ideas (see below). |
| |
| For open bug reports refer to |
| \url{http://www.rockbox.org/tracker/index.php?type=2} |
| |
| \subsection{Rules for submitting new bug reports} |
| |
| \begin{enumerate} |
| \item Check that the bug has not already been reported |
| \item Always include the following information in your bug report: |
| |
| \begin{itemize} |
| \item Which exact \dap{} you have. |
| \item Which exact Rockbox version you are using |
| (Menu $\rightarrow$ System $\rightarrow$ Rockbox Info $\rightarrow$ Version) |
| \item A step{}-by{}-step description of what you did and what happened |
| \item Whether the problem is repeatable or a one{}-time occurrence |
| \item All relevant data regarding the problem, such as playlists, MP3 |
| files etc. (IMPORTANT!) |
| \end{itemize} |
| \end{enumerate} |
| |
| \section{Feature ideas} |
| To suggest an idea for a feature or to read those made by others, see |
| \url{http://forums.rockbox.org/index.php?board=49.0}. Please keep in |
| mind that this forum is for the discussion of feature ideas - they are not |
| requests and there is no guarantee they will be acted upon. |
| |
| \subsection{Rules for submitting a new feature idea} |
| |
| \begin{enumerate} |
| \item Check that the feature has not already been suggested. |
| Duplicates are really boring! |
| \item Check that the feature has not already been implemented. |
| Download the latest current/daily build and/or search the mail list archive. |
| \item Check that the feature is possible to implement (see \reference{ref:NODO}). |
| \end{enumerate} |
| |
| \subsection{\label{ref:NODO}Features we will not implement} |
| This is a list of Feature Requests we get repeatedly that we simply |
| cannot do. View it as the opposite of a TODO! |
| |
| \begin{itemize} |
| \opt{archos}{ |
| \item Record to WAV (uncompressed) or MP3pro format.\\ |
| The recording hardware (the MAS) does not allow us to do this |
| \item Crossfade between tracks.\\ |
| Crossfading would require two mp3 decoders, and we only have one. |
| This is not possible. |
| \item Support MP3pro, WMA or other sound format playback.\\ |
| The mp3{}-decoding hardware can only play MP3. We cannot make it play other |
| sound formats. |
| \item Converting OGG $\rightarrow$ MP3.\\ |
| The mp3{}-decoding hardware cannot decode OGG. It can be reprogrammed, but |
| there is too little memory for OGG and we have no documentation on how to |
| program the MAS' DSP. Doing the conversion with the CPU is impossible, since |
| a 12~MHz SH1 is far too slow for this daunting task. |
| \item Archos Multimedia support.\\ |
| The Archos Multimedia is a completely different beast. It is an entirely |
| different architecture, different CPU and upgrading the software is done |
| a completely different way. We do not wish to venture into this. Others |
| may do so. We will not. |
| \item Multi{}-band (or graphic) equaliser.\\ |
| We cannot access information for that kind of visualisation from the MP3 |
| decoding hardware. |
| \item CBR recording.\\ |
| The MP3 encoding hardware does not allow this. |
| \item Change tempo of a song without changing pitch.\\ |
| The MP3 decoding hardware does not allow this. |
| \item Graphic frequency (spectrum analyser).\\ |
| We cannot access the audio waveform from the MP3 decoder so we cannot analyse |
| it. Even if we had access to it, the CPU would probably be too slow to |
| perform the analysis anyway. |
| \item Cool sound effects.\\ |
| Adding new sound effects requires reprogramming the MAS chip, and we cannot |
| do that. The MAS chip is programmable, but we have no access to the chip |
| documentation. |
| } |
| \nopt{iriverh300,iaudiox5}{ |
| \item Interfacing with other USB devices (like cameras) or 2 player games over USB.\\ |
| The USB system demands that there is a master that talks to a slave. The |
| \dap{} can only serve as a slave, as most other USB devices such as |
| cameras can. Thus, without a master no communication between the slaves |
| can take place. If that is not enough, we have no way of actually |
| controlling the communication performed over USB since the USB circuit |
| in the \dap{} is strictly made for disk{}-access and does not allow us |
| to play with it the way we'd need for any good communication to work. |
| } |
| \item Support other file systems than FAT32 (like NTFS or ext2 etc.).\\ |
| No. |
| \opt{archos}{Rockbox needs to support FAT32 since it can only start off a FAT32 |
| partition (since that is the only way the ROM can load it), and adding}% |
| support for more file systems will just take away valuable ram for |
| unnecessary features. You can partition your \dap{} fine, just make sure |
| the first one is FAT32 and then make the other ones whatever file system |
| you want. Just do not expect Rockbox to understand them. |
| \item Add scandisk{}-like features.\\ |
| It would be a very slow operation that would drain the batteries and |
| take a lot of useful ram for something that is much better and faster |
| done when connected to a host computer. |
| \item Alphabetical list skipping.\\ |
| Skipping around the lists by jumping letters (i.e skip all C's and go |
| straight to the first D). This isn't feasible with the current list |
| implementation, if you really want this you can get similar effects using |
| the database (see \reference{ref:database}). |
| \item Add support for non standard tag formats.\\ |
| APE tags in MP3 files has been rejected a few times already. Its not something we want. |
| \item Implementing the ability to playback DRM files.\\ |
| Firstly, this would be extremely difficult to implement legally - Rockbox |
| is not legal entity as such, and therefore is unable to enter into license |
| agreements with providers of DRM technology. |
| Secondly, Rockbox is open source, which would mean that any DRM technology we |
| incorporated into our codebase would suddenly become visible to the whole world, |
| completely defeating its purpose. Remember, DRM achieves part of its security |
| through obscurity, and publishing the keys necessary to decrypt DRM'd |
| media would essentially render it useless. |
| \end{itemize} |
| |
| \chapter{Credits} |
| People that have contributed to the project, one way or another. Friends! |
| % |
| \begin{multicols}{2} |
| \noindent\caps{\small{\input{CREDITS.tex}}} |
| \end{multicols} |
| |
| \chapter{Licenses} |
| |
| \section{GNU Free Documentation License} |
| \input{appendix/fdl.tex} |
| \newpage |
| \section{The GNU General Public License} |
| \input{appendix/gpl-2.0.tex} |