Data: http://www.apple.com/autopush/us/itunes/includes/countdown.txt
JavaScript: http://images.apple.com/global/scripts/downloadcounter.js
There is a text file. The text file is obviously coming out of the iTunes store. It contains the hourly timestamp, the count of the number of apps sold and the current sales rate.
15-APR-2009 21:00:00|960384867|260839
Based on this information, we are just 39,615,133 apps shy of the billionth app and 260,839 apps are bought in a certain period of time. What is that period of time. If you look at the JavaScript code, you can see they are dividing that number up in to 3,600,000. I take this calculation to be in milliseconds. By extrapolation that means that 72 apps are bough every second. That would seem to jive with the animation.
The burn rate is not constant. If the burn rate were to remain constant then we would be just 546,752 seconds away from the billionth app. The make the event scheduled for just lest than a week from now (6 days, 7 hours, 52 minutes).
Wednesday 4/22, 7:52 am Central Time
The data file is refreshed every hour so this estimate is also subject to revision every hour. With only nine hours of data the target time floated from 4/22 to 5/1 and now has begun to drift back. This sine wave is caused by the daily traffic pattern of the Apple Store. If I continue to monitor the store for another day or two I should be able to average in on the target. The average target is now 4/26/09 2:12 PM… 4/26/09 11:26 AM… 4/26/09 9:04 AM… 4/24/09 12:15 PM… 4/24/09 5:28 PM… 4/23/09 10:22 PM… 4/23/09 3:11 PM… 4/23/09 3:16 PM
Here’s my Source Data on Google Docs: http://spreadsheets.google.com/ccc?key=pydmD4NiOSHYPmIfdh1j4Dw
That would seem to jive with the animation.
Now they are counting down to the 10 billionth song.
http://www.apple.com/itunes/10-billion-song-countdown/