HTTP Streaming WAV audio no longer works with quicktime 7.7.3 OSX or 7.7.5 in windows

Post a URL so we can test your site and page code.

Your file uses an out of date audio codec that is no longer supported by the QuickTime browser plug-in.

That is an unfortunate but, given the symptoms, expected explanation. I say unfortunate as G.711, far from being out of date, is still currently used in much of IP telephony: dropping support makes it difficult to serve raw audio (which our customers demand) using quicktime. Luckily, other products still properly play these payloads, still - it would have been nice if quicktime release notes noted dropping support for codecs.

As QTKirk pointed out, the μ-law algorithm is a legacy PCM audio compression format. However it would be incorrect to say it is no longer supported. The problem appears to be your use of the WAV file container. Basically you are confusing the playback handler with WAV extension. On the other hand, if you place the data in the MOV file container, you would have a better chance of having the compression format and file container combination being more universally recognized and being played properly. Try the following URL for the file:

http://downloads.walker4.me/Temporary_files/wavtest.wav.mov

It's got to be the browsers? I can play none of the links with Windows 7. With all updates from Microsoft, including one today from Microsoft for Internet Explorer11. In referring to the post > QuickTime 64-bit Chrome plug-in. Kirk sent a good link.

http://www.cnet.com/news/soon-to-be-banned-chrome-browser-plugins-get-reprieve/

http://www.cnet.com/news/soon-to-be-banned-chrome-browser-plugins-get-reprieve/

It might be possible to repackage as mov or something else supported on the fly, but it still feels like this may be an oversight/bug in the latest versions of the quicktime plugin rather than a conscious decision to drop support.

By default, I believe QT is expecting to find 16-bit LPCM encoded audio when it opens a WAV, AIF, or AU file container. Since the µ-law algorithm is 8-bit, QT X fails to "recognize" the audio compression format while placing the 8-bit µ-law in the generic MOV file container forces QT to identify the actual codec involved in order to determine which audio codec is required for playback. At this point my guess is that you can either put the 8-bit µ-law data in an MOV file container so it will be more universally recognized or use a different 16-bit LPCM codec (WAV, AIFF, Sun Microsystems, etc.) which are more universally compatible in their own unique file containers (e.g., WAV, AIF, AU, etc.). My previous answer assumed you wanted to continue to use the legacy codec which, in its default form, produces smaller output files since, in comparison, the default setting 16-bit AIF and WAV files for your 1.1 MB 8-bit content would be 12.7 MBs while the AU conversion came in at 2.1 MBs.

Jon, the browsers are not allowing most plug-ins to kick in. Read about it, Yikes!

Jon, the browsers are not allowing most plug-ins to kick in. Read about it, Yikes!

If you re-read the entire topic you will note the discussion includes issues regarding Safari plug-in playback under Yosimete and questionable Safari playback on mobile devices under IOS 8. Here are screen recordings of playback of the "re-containered" data in Safari under both Yosemite and IOS 8:

Safari under Yosemite

Safari under IOS 8

hmm. well, re-containerizing the actual files is intractable for a variety of reasons.

For the sake of my curiosity, is there some special reason why you are using a legacy 128 Kbps @ 8 KHz PCM format rather than a more modern, more efficient format like AAC 128 Kbps @ 160 KHz producing a file of similar size but higher potential quality?

Jon, I read. But the links to websites are not playing on a Windows7 computer. Can you tell me why they are not?

Jon, I read. But the links to websites are not playing on a Windows7 computer. Can you tell me why they are not?

I believe that with a new dawn comes new understanding of the problem.

1. I do not have access to a Windows 7 computer nor do I run Windows on my Mac.
2. I am not a web coding programmer. However...
3. Neither of the original poster's links (http://openmap.bbn.com/~mthome/quicktimeaudio.html and http://openmap.bbn.com/~mthome/wavtest.wav) work because they both point to the same HTML (quicktimeaudio.html) file.
4. The HTML file looks like this:
5. This file appears to look for the QT plug-in to see if QT is installed, if the version is v7.7.6, and whether or not the WAV extension is supported.
6. When I click on either link, this is what I see:
7. Although I am running:
   
   the browser display shown above indicates the HTML code thinks that QT is not installed rather than being the wrong version and then, instead of terminating the browser processing and displaying the correct error message, the HTML code falls through to a display of the audio media controller and automatically starts playback. Unfortunately, since confirmation of WAV playback support was skipped (or for some other reason), the QT plug-in does not access the required codec (or fails to send the data to the handler) and no audio is heard when playing the WAV audio file. In short, even though I am not a web programmer, I believe the main issue here is the coding of the HTML file.
8. When I "re-containered" the original poster's WAV file and posted it on my own server, I created a URL link that actually pointed to the WAV resource and not to the HTML file code as did the OP's secondary link. Thus, when I accessed the audio file, I did so directly via the plug-in, by-passing the HTML file code issue and allowing the file data to play correctly in Safari under both Yosemite and IOS 8.
9. Believe the HTML file needs to be re-coded to fix the problem. I can now play the original 8-bit µ-law encoded WAV file in players and Safari but believe the OP here should consider a more modern compression format/file container combination that would allow him to abandon use of the QT player plug-in to maintain compatibility with "plug-in free" browsers. For instance, would HTML5 coding be able to play AAC encoded content in MOV, MP4, M4V, and/or M4A file containers? Once again, questions like this are beyond my expertise and need to be answered by someone proficient in this area.

As I mentioned before - while it is old, it is not a legacy format: it is essentially the current default formal for digital telephony worldwide: ITU G.711 PCM using either ulaw or alaw at 8000Hz: If you used a telephone today that included a party in North America or Japan, some or all of your call was almost certainly encoded in precisely the format of my original sample. The WAV containerization is a somewhat arbitrary choice, but convenient and (the current issue notwithstanding) broadly supported. While there are plenty of other formats available, this is universally supported by all systems for basic guaranteed interoperability. Obviously, there is zero benefit for us in using different codecs in search of higher quality given that the basic signal is this format. There is certainly an argument to be made for using higher compression codecs, but our customers will often not accept lossy algorithms (I know, I know) and there are significant operational benefits for fixed bitrate storage to disk.

Assumption that data needed to be re-wrapped was erroneous based on inability to play your secondary link in either player until I copied the data to an MOV file container, posted it to my own server, and then retried QT X, QT 7, Safari, and IOS 8 playback options. My mistake. This AM I took a quick look at the HTML file that seems to be causing the issues. Conditional testing is telling Safari that QT is not installed and then proceeds to play the content "silently" anyway. In any event, the original 8-bit PCM played fine in the WAV container this morning once I by-passed your HMTL coding. This format may be fine for telephonic communications but is "legacy" as far as HTTP streaming is concerned which is moving on to newer, more modern, and more efficient, higher fidelity codecs that are better adapted to "plug-in free" coding trends that natively support multiple browsers. I fear the days of using your current "plug-in" strategy are numbered.