(Posting here because I have no idea where else to ask.)

Consider this SWF: http://swfchan.com/3/11576/?ruff.swf
When it was published back in 2004, it was pretty much on sync (at least on IE6, Windows XP and Flash 7, I think. Not in Firefox - this has already been an issue back then). Now it's not anymore.
What happens now: Even though I have this file on my hard disk, it starts off pretty slow, and then continues playing faster after one iteration - but not always.
Even when it doesn't start off slow, the video itself is a bit slower than what it ought to be. The video is supposed to play exactly 5 times for one full play of the audio track. Even when you extract the FLV and play it with VLC, the speed is different (not exactly sure if it's the correct speed with VLC).
I have spent many hours trying to inspect the file with different tools, but I really can't see the problem...

TL;DR
(1. Which are the factors that caused the SWF to not be in sync anymore?)
2. How do I get the SWF to play the video in real time? (5 video plays for one audio play. - It used to play fine.)

The only way to fix this is to modify the flash file (make a new flash) by locking the visuals to the audio (using streaming audio). This will increase the file size and cause a small glitch when the timeline actually rewinds (though it's possible that future plugins will make this glitch smaller and smaller). File size is only increased if you repeat the same audio several times by extending the visuals a couple of iterations in order to make the glitch not appear on each and every audio repeat.

A different option is to make the visuals a bit shorter than the audio and begin playing the audio every time the first frame is hit. This will resync the audio with the visuals every time the visuals repeat, however there will most likely be an audio overlap or a brief period of silence before the audio repeats. If the flash is not in view the frame rate will drop to 1 if I remember correctly (to save CPU, a somewhat new feature of flash), which will make the audio gap between repeats huge (therefore loops that use this audio-resync-on-each-first-frame method will unfortunately not be very enjoyable if you have the flash open in a different browser tab, due to the very long period of silence between repeats, therefore I don't recommend this method but instead the first one I wrote).

Then again I don't really think you should care about having perfect sync in flash loops - it's accepted that they desync after a while. Only if constant visual/audio timing is super duper important should it be considered and as I said then I only recommend streaming audio (twice is a decent repeat number - will cause at least one seamless (fake) loop without a glitch in the audio and it will "only" double audio size. But of course, if the audio is small it's not as costly to repeat it several times, file size-wise).

>maybe the flash plugin of 2004 caused the visuals to be delayed a little bit more when it rewinded back to the first frame
I don't understand that delay. On current browsers and Flash versions the SWF is played more slowly at the beginning. If the current way of display is more correct, then I don't find the causing SWF Tag or bits in the file above.
What is more, how come (back then) on Firefox the SWF played differently than in IE? Wasn't it the same flash player version?
And one more question that came to my mind: If you include a WAV audio file in a SWF on the flash editor, then the loop is seamless, although it gets converted in MP3. As far as I know, MP3 files always have a small silence at the beginning. And when you extract that MP3 (without converting it), then you indeed have that silence, that isn't played by Flash. How come?

Though I don't know for sure why Firefox and Internet Explorer played flashes a little differently in the past it was probably because IE used (and still uses) the ActiveX version of the flash plugin while other browsers does not. There are actually two different flash installers depending on if you're using IE or not. Also, IE was coded differently which could have affected flash playback.

It always annoyed me that the MP3 format requires a bit of silence in the beginning and end, thanks to these official specifications a MP3 should not be able to repeat seamlessly. What I think flash is doing however is cheating, either by skipping these gaps upon playback or by making a gapless MP3 upon build of the swf file (which breaks the official mp3 format specifications).

To this day I still haven't figured out exactly what magic it does to its Mp3s because if it makes a gapless Mp3 it should be possible to export the mp3 from the swf file, but those always seems to turn out as non-gapless mp3s (maybe programs like Sothink SWF Decompiler are "fixing" the mp3 to follow official specifications upon export? Seems unlikely since all such decompilers does it). On the other hand, if flash simply skips leading/trailing gaps in mp3s it should be possible to use mp3s in flashes and have them loop seamlessly, however then flash takes into account the gaps of the imported mp3. Is it built in to then respect the gaps, by flagging the mp3 somehow, or by adding small additional gapsto the track? Not likely since when you make a swf by not using official tools flash always plays gaps of mp3s and you have to make the mp3 gapless yourself before import (though it still doesn't work as well as when using the official flash making program).

If someone understands exactly what flash does to make their mp3s loop seamlessly I'd appreciate if he posted here.

On the gap issue: With which program did you check that there is a gap in the decompressed mp3 file? The gap could be the decoders "fault", like LAME does. Here's one idea to test it, if you have official tools available (I haven't):
Create a SWF file with a WAV track and check if it really loops seamlessly. Extract the MP3 audio track from the created SWF, and create a *new* SWF using the extracted MP3.
If it still loops seamlessly, then we can assume that only the combination of flash encoder *and* decoder result in a perfectly loopable MP3. It could also mean that the audio track isn't flagged in some way, but flash breaks the official specification.

I did a quick test doing what you suggested (just to be sure) and the exported MP3 from the swf file had exactly 0.060952 sec of silence added to it by Sothink's SWF Decompiler (counting both beginning and end silence). I took that MP3 file and made a quick flash loop of it using Adobe's official Flash program and indeed the gap was there (told Flash to use imported mp3 quality so it wasn't re-encoded).

That's why I always recommend using WAV files when creating seamless audio loops in flash, otherwise there will always be a gap of silence upon repeat.

Foor good measure I exported the mp3 file from the new swf I just created, turns out the total silence gap was now 0.086944 sec. Interesting because it means Sothink adds silence upon export even if there already is silence. Note how only 0.025992 sec of silence were added now, roughly 2.5 times shorter than the first time. Strange.

I check for gaps using Audacity 1.2.3, but you can hear it too just by queueing up the two mp3s after each other in WinAmp. Although it's odd because WinAmp should skip the gaps to provide seamless transactions between songs (for example some CDs have that). Could this mean that the gap I'm seeing in Audacity and hearing in WinAmp and the new swf file is not actually the leading trailing gaps of the mp3 format, but instead just gaps that Sothink adds on its own for some reason? Yes it could mean that. However then you should able to loop mp3s in flash seamlessly, however you can't unless you import them as wavs and export them as mp3s (where Adobe does the exporting).

Using Audacity I took a seamless wav audio loop and exported it to mp3 (using the lame_enc.dll library). I then imported the wave of the mp3 into Audacity. Around 0.025 sec of silence was added to the audio (only at the beginning, nothing at the end! Notice how this is the same amount that Sothink added to the mp3 the second time. If I repeatedly imported and exported the mp3 in Audacity it prolonged the audio with 0.025 sec of silence each time at the beginning (after three times the silence was around 0.075 sec).

Further interesting is that WinAmp picked up the gap, it didn't skip playing it. Meanwhile I found two mp3s from a CD that had seamless transition between two songs in WinAmp, when I imported those mp3s into Audacity they had silence at the beginning and end as well. Does this mean that the LAME mp3 library is to blame, or what?

How Mp3s work exactly is outside my area of expertise, we need a real mp3 expert to come along and help us to figure this out. But it seems to me that Flash does something with their mp3s upon export to make them gapless, and then Sothink "fixes" them when pulling those tracks out of the swf file. Best would be if a flash format dev from Adobe or old Macromedia explains it though, but I doubt it will happen. Maybe there's some documentation in the depths of the web, somewhere.

That's really strange with the MP3s. Actually most extractors I've encountered extract the MP3 without altering it. I think I remember to have used a hex editor and found the extracted MP3 exactly in the (unpacked) SWF.

The gap you've seen with Audacity could've been the decoder's fault, but I'm just guessing. Also the WinAmp thing baffled me a bit. But right now I've run out of ideas...

Maybe you want to check out the LAME Technical FAQ: http://lame.sourceforge.net/tech-FAQ.txt
It has information on why there's a silence before and after, but it still doesn't answer how flash handles audio formats.

>used a hex editor and found the extracted MP3 exactly
So the swf contained a mp3 with gaps yet the audio appeared seamless when looping in the flash? Hm.

Would be interesting to continue researching about the mp3-swf oddness, but I've done a bit of that in the past and it got me nowhere. Seeing as I won't be using the information for anything right now I'd rather just drop it. I guess you're just not supposed to know some things in life.

Also, one could take a look at the source code of e.g. SWFTOOLS. I did (not being an expert), and think that the MP3 gets extracted without conversion or modifying. I checked what I said with the hex editor, and it's true (had to install one first from source - long story). I'm trying to stick to this, but it is very difficult to find boards with people who have deep knowledge about the SWF format.

When you encode audio to MP3, there's silence added at the beginning and/or end. Afterwards, it's impossible to find out how many samples of silence have been added exactly; among other things this is because MP3 can't have "pure" silence (i.e. amplitude of 0) - but I'm unsure about this point. However, if you encode your seamless WAV file with the Flash IDE, the original amount of samples is stored in the SWF file (SeekSamples and SoundSampleCount). This way, the SWF decoder can deduce where the useful part is located in the MP3 file.

There's still one problem: I found out the number of samples and extracted the MP3 file, but when I extract that amount of samples from the audio, there's still a tiny little gap, and it still doesn't play as smooth as in the browser. I suppose there's another calculation to be done, which I haven't found out yet.

http://wwwimages.adobe.com/www.adobe.com/content/ dam/Adobe/en/devnet/swf/pdf/swf-file-format-spec.p df

SoundSampleCount is part of the DefineSound tag (page 178) but it seems the interesting stuff is in SoundInfo (page 180). InPoint and OutPoint seems to define where the actual audio starts and ends.

So now we know Flash doesn't do anything with their mp3 upon export, they simply store where the audio begins and ends in the mp3. So if I want to improve my flash loop maker service in the future I should scan the created flash file for any SoundInfo blocks and modify the InPoint/OutPoint values. I don't have plans to do it right now but maybe someday, thanks for letting me know this! Flash is such an amazing format, but it isn't easy to work with once the swf file has been compiled.