Known Issues

- My songs play at the wrong speed... mp3s played through flash play too fast or too slow.
- Flash will not display "progressive" JPG images.
- Mozilla FireFox and Macromedia Flash issues.
- FrontPage issues.
- Video "freaks out" or won't play properly.
- Windows IIS server won't display FLV files.
- ASP pages don't show up on Windows 2003
- The play position indicator stays near the start as if it was playing an incredibly long file. When the movie runs out, Wimpy gets stuck and can't go on to the next track on its own.
- Some special characters do not display properly (åäöÅÄÖ).
- File size limitations
- FLV files do not show up in Wimpy AV. What gives?

My songs sound like they were recorded by chipmonks... they play "too fast"

The issue with the "chimpmonk" effect is due to the way that the mp3 was originally encoded. Macromedia Flash can handle most standard mp3 encodings with any bitrate. However, some mp3 encoders use "non-standard" encoding technics that Macromdia Flash can not handle... I have only been ablt to reproduce the "chimpmonk" effect while using musicmatch's mp3PRO setting. The standard mp3 setting in musicmatch works fine, but when a file is encoded with the mp3PRO setting the file plays through wimpy with the "chimpmonk" effect... I have been unable to find documentation on this issue on Macromedia's web site. This issue is not a function of wimpy, but rather an issue with the Flash plugin. The only solution i can offer at the moment is to re-encode your mp3's with a standard mp3 encoder. Wimpy will support VBR encoding and any bitrate. just be sure that you don't use mp3PRO encoding.

A good mp3 encoder is dbPowerAmp, which is what I currently use. It's a small, right-click type utility that makes encoding an mp3 a snap. Usig the standard settings in dbPowerAmp works great with Wimpy.

James Roy has discovered the following:

"Just an FYI, I encountered the "chipmunk" problem as well when I used the Wimpy Button because I was encoding MP3s at 96kbps using iTunes. An MP3 encoded at 128kbps seemed ok, but anything else (even encoding the files first at one bit rate, and then another) gave me either a faster or slower playing speed."

"I looked at your FAQs and found that this problem has been documented, but not solved."

"I was able to solve my problem by going into iTunes prefs, choosing 'custom' for the MP3 encoding, and then choosing 44.1kHz for the sample rate instead of 'auto'. Apparently when iTunes uses an auto bit rate, the Flash player is unable to adjust its playing speeds to accomodate the optimized MP3 file."

"So, if other customers come to you with this problem, make sure that they have specified the bit rate at 44.1kHz instead of letting iTunes choose."

James Koenig dicovered the following:
Flash goes all chipmunk on a LAME encode at 40kbps mono, but works at 32

Jack at Jukebox Alive notes:

For low bitrates (less than 32) I have the option of resampling at:
8 khz.
11.025 khz.
12 khz.
16 khz.
22.05 khz.
24 khz.

Of those, flash seems to only play nice with 11.025 or 22.05, it was defaulting to 24

John Henry Mostyn notes:

...A slightly more robust answer to the resampling issue for
users of Lame mp3 encoders, an additional call to -- resample 22.05
will force the sample rate flash seems to need for compact mp3s

One additional note:
It seems as though you should always try and "set" every configuration. Leaving your compression utility to "auto" or "default" is probably not a good idea.

Older versions of Firefox (prior to FireFox version 1.0) have issues with the Macromedia Flash plugin... And since Wimpy uses the Macromedia Flash plugin, those who use older version of Mozilla FireFox will have "issues" -- it is recommended that you inform those who use older version of Mozilla FireFox to upgrade their FireFox browser to at least version 1.0.

Wimpy has not been tested with Microsoft FrontPage. We do not recommend FrontPage because FrontPage has a tenancy to alter HTML after it has been incorporated into your page.

If you use the Customizer Tool at wimpyplayer.com to generate an HTML snippet or HTML page and save the HTML... FrontPage may change the HTML without warning or notification. Since FrontPage alters the HTML code the Customizer Tool HTML may cause wimpy to no function properly.

There is some documentation out there on the web that lets you prevent FrontPage from altering the HTML code, but this "work around" has not been verified, and is not guaranteed to work.

Please refer to the links below.

Source: http://www.crosswinds-cadre.net
To prevent FrontPage from altering your code as it saves or uploads, click Tools»Page Options»HTML Source, and choose "Preserve existing HTML".

Source: http://www.onestat.com
# 10.  I am using Microsoft Frontpage 2000 but still have difficulties
If you edit your pages with FrontPage 2000 and are experiencing problems with your stats, it's most likely due to FrontPage altering the OneStat code. Please delete the OneStat code out of your page and follow the steps below:
-View your page in Design View (default view).
-Click on bottom of page.
-Click Insert > Advanced and select "HTML".
-Place your cursor where you'd like to insert the OneStat code.
-Insert the OneStat code between the body tags.
-Click "Ok"

Here are a couple alternate things you can try:

1. You **should** be able to access wimpy.asp directly. This will not allow you to use a custom skin though. However, you can edit the "options" by editing the variables within the wimpy.asp page. Open wimpy.asp in a test editor and refer to the notes within the code of the page.

2. If you decide to save an HTML file from the Customizer tool. Try saving the Customizer output file with an "asp" extension rather than an "html" extension. Example: rather than myWimpy.html, save as myWimpy.asp.

There may be an issue with Windows 2003 Server not streaming FLV videos. The issue basically hinges on the FLV extension not being recognized as a MIME type, hence the server doesn't know how to handle the file.

The proper mime type for FLV video is:

flv-application/octet-stream

Click here for the Macromedia Knowledgebase Article for detailed information on fixing this issue on your server.

See also:
ASP pages don't show up on Windows 2003 Service Pack 1

Dave Brown discovered the solution: In Windows 2003 ASP is disabled by default. To enable it you need to run a script on the server:

cscript %systemroot%\system32\iisext.vbs /EnApp "Active Server Pages"
Click here for more info

Also:

Windows 2003 server with IIS - If the wimpy.asp file does not load properly, try flip-flopping lines 15 and 16. (So that line 16 is now on line 15 and vice vers). [Thanks to Mike Shearin ms673 at hotmail.com]

Click here for answer

There are issues with ASCII characters above 255 (i.e. some swedish, german and french characters like åäöÅÄÖ).

The issue revolves around the ability of PHP to output double-byte characters properly. Check with your server administrator to see if they can re-build PHP with the mbstring extension "-with mbstring"

This is a know issue in the podcast scripts. We're working on a resolution.

Technically, there is no limit to the size (MB) or length (in seconds) of the files that can be played through Flash.

Some Windows servers may "cap" files at 2MB or 4MB, which may cause issues whn using the following options:

- Prevent files from caching
- Startup folder
- Force download

The issue is that the Windows server is configured to limit files that are downloaded based on the configuration settings for AspBufferingLimit in Metabase.xml.

Click here for more information on how to resolve this issue.

Aside from Windows issues mentioned above, 10MB files run through wimpy without a hitches. We atually had a 10MB file running through on the home page for quite some time, but decided to take it off to curb our bandwidth. Other folks have run 20-40MB files that were 30-60 minutes in length without any problems.

There are a number of factors that can play a role in the issue, such as:

• The end-users system capabilities, RAM, CPU, HD space and firewall or router settings, service limitations, internet connection speeds, network traffic or server CPU, RAM and bandwidth capacities.
• Upload / download / bandwidth constrains on the server.
• If you are using a web-interface (a web page / script) to upload files, often times, the script that handles the upload puts a limit on the size of the file that the script can upload. If the file limit is exceeded a number of things can happen that will cause the file to become corrupted.

As you can see there are many variables to consider with this issue.

Lame recommendation: The best thing to do would be to "be reasonable" with the size of the file you are attempting to use. I recommend keeping your file sizes down to a maximum of 10 megs. File sizes larger than 50-60 MB will take quite some time to download -- even for faster connections. If you split the files into smaller increments you will probably run into less problems for yourself and for those who use your site.

Wimpy is based on Macromedia Flash, so any limitations of this nature would most likely be available for review through Macromedia. I was unable to locate any information on Flash filesize limitations at the Macromeida web site at the time of this writing.