Newer FAQ entries are at the top. 

1. Some of my MP3s show the wrong bitrate.  Help!
   While ShufflePlay has a fairly accurate bitrate detection system, there are still a few that slip through the cracks.  There is a way to catch these, but it would greatly slow down the software, since it would need to play the first few frames of each MP3 that it scanned to verify the bitrate.  Maybe a "Use slower high-accuracy bitrate detection" option will be added in the future.
   
     
2. Tag & Rename doesn't work.  Why?
   Keep experimenting.  Be sure to read the Help tab carefully.  Once you get the hang of it, tagging and renaming your files will be a piece of cake.
   
    
3. ShufflePlay crashes when I...
   Are you using the latest version?  If so, please contact us with details about the bug, what error message comes up, and steps to reproduce it.  The more information we have, the better chance there will be to fix the problem.
   
    
4. These genres are terrible!  Primus has their own genre?  Could you please add  <my genre> ?
   ShufflePlay currently supports the ID3v1 specification as extended by the developers of Winamp for consistency.   We will move on to support some kind of 'custom genre' system in the future.
   
   
5. How do you make the Text/HTML Publisher, sort the output by title/artist/album/etc?
   Easy.  First, sort the playlist by whatever criteria you are using.  Then use the Publisher as usual.  The output will retain the same sort order as the playlist.
   
   
6. ShufflePlay skin support?
   Nah...I don't think so.
   
   
7. I see the ID3v1 support, but where's the ID3v2 support?
   I agree with the following comments from the author of MP3 Manager:

   Few reasons, why MP3 Manager 32 does not support ID3v2:

   1. The ID3v2 system is complicated and its implementation is unproportionally demanding.
   2. What's even worse - In my opinion ID3v2 system can be dangerous to hardware (hard disk): Position ID3v2 tag on beginning of mp3 file implies that every change in ID3v2 tag requires moving all the stuff that will go after the new information. So to add or make changes to an existing mp3 file would require moving all the music data, even if one just changes few bytes in the tag. But moving around big amounts of data is slow and can cause hard drive damage. Most people never have a hard disk failure simply because they don't move much data around often. But with a prefix tag, there would be more moving than usual. Couple this with the fact that mp3s are generally around 4MB and you have lots of data moving fairly often. Using any mass-editing function could then lead to hard disk failure. On the other hand I agree that position on beginning of file is good for streaming... but most mp3's are played from HD.
   3. It will be impossible to detect bitrate from mp3s with ID3v2 added for helper/playlist/player frontend mp3 software which is non-ID3v2 compliant, because all such not-directly playing software recognizes bitrate from header of first frame located on beginning of mp3 file.
   4. I really don't think that mp3 file should contain other binary data as pictures - on the contrary to lyrics text which should be added into mp3 file because of eliminating FAT space loss. Will you perhaps add image for album cover into all tracks from album? Linking to local image file is so simple...