>>> You should use the HTML 5 <audio> tag nowadays. It supports MPEG-1 Layer
>>> 3 (aka MP3) and Ogg-Vorbis as compressed formats.
>> Does this obviate my suggestion to use something like jplayer to make
>> it compatible with the various user devices?
>No dedicated player is requred to play HTML 5 content. Jplayer is just a
>jQuery based Software that can deal with non HTML 5 compatible clients
>too, e.g. based on Flash - iih, I wrote the ugly word.
>I would not spend much time in non HTML 5 compliant software nowadays.
Okay, this does indeed work on a few devices that I've tried so far.
So if the OP does not need to support pre-HTML5 devices, then this
would seem by far the simplest thing to do.
Some googling suggests this is good for Android 4.0 and later,
iOS 7.0 and later.
Steve
Reply by Marcel Mueller●September 24, 20162016-09-24
On 24.09.16 16.21, Steve Pope wrote:
> Marcel Mueller <news.5.maazl@spamgourmet.org> wrote:
>
>> You should use the HTML 5 <audio> tag nowadays. It supports MPEG-1 Layer
>> 3 (aka MP3) and Ogg-Vorbis as compressed formats.
>
> Does this obviate my suggestion to use something like jplayer to make
> it compatible with the various user devices?
No dedicated player is requred to play HTML 5 content. Jplayer is just a
jQuery based Software that can deal with non HTML 5 compatible clients
too, e.g. based on Flash - iih, I wrote the ugly word.
I would not spend much time in non HTML 5 compliant software nowadays. I
especially dislike when each website uses its own non-standard way of
multimedia playback. Mainly because every website has a different user
interface which I need to use. And some of these self made UIs are
extraordinary bad. Think also about accessibility and people with
disabilities, an emerging market. E.g. screen readers are often confused
by script hacks. Even though jplayer is probably one of the better ones.
> If so, it sounds pretty simple as far as the web code is concerned.
It is even more simple. Just write
<audio src="my_file.mp3" controls/>
and you are done. Jplayer mainly adds eye-candy to that.
Marcel
>You should use the HTML 5 <audio> tag nowadays. It supports MPEG-1 Layer
>3 (aka MP3) and Ogg-Vorbis as compressed formats.
Does this obviate my suggestion to use something like jplayer to make
it compatible with the various user devices?
If so, it sounds pretty simple as far as the web code is concerned.
Steve
Reply by Richard Owlett●September 24, 20162016-09-24
On 9/23/2016 4:50 PM, eric.jacobsen@ieee.org wrote:
> On Fri, 23 Sep 2016 15:13:40 -0500, Richard Owlett
> <rowlett@cloud85.net> wrote:
>
>> Notice I've deleted all replies? <chuckle>
>
> This is usenet. Nothing got deleted. It's all still there,
> archived forever.
>
>> Though deleted, they have educated me ;> !!
>>
>> The "answer" [please note quotation marks] *AS ASKED*
>> legitimately range from
>> less than "1 MB /sec" to ">3 MB /sec".
>>
>> This leads to multiple questions:
>> 1. Does a host care how an audio file is encoded?
>
> What sort of host are you talking about? The mission and resources
> of the server may dictate what tradeoffs make the most sense for a
> particular context.
We are having someone design and host the site. I've seen the
budgetary estimate but it wasn't that detailed. I don't know just
what questions were asked that prompted the estimate.
>
>> 2. What encoding can a modern browser handle transparently?
>> [The last time I retrieved an audio file was when dial-up
>> was SOP ;]
>>
>> Assume I'm totally ignorant. A certain resident on PLUG might
>> cheerfully certify same.
>
>
Reply by Richard Owlett●September 24, 20162016-09-24
On 9/23/2016 4:04 PM, Steve Pope wrote:
> Richard Owlett <rowlett@cloud85.net> wrote:
>
>> Notice I've deleted all replies? <chuckle>
>> Though deleted, they have educated me ;> !!
>>
>> The "answer" [please note quotation marks] *AS ASKED*
>> legitimately range from
>> less than "1 MB /sec" to ">3 MB /sec".
>>
>> This leads to multiple questions:
>> 1. Does a host care how an audio file is encoded?
>> 2. What encoding can a modern browser handle transparently?
>
> Unfortunately, assuming you want to support PC's, MAC's, and
> both Apple and Android mobile devices, and you want this
> to stream on all these devices (as opposed to, or in addition to, allowing
> file download), you're going to have to support several filetypes
> and possibly embed a player such a jplayer into your website.
>
> A typical Android phone with no extra apps installed will not
> stream audio from a typical audio-streaming website, even when
> it's an mp3 stream. (This deficiency creates an entire business model
> for Tunein, a startup out of San Francisco, which basically is paid by
> broadcasters to create a website/app combination that reliably streams.)
>
> For what you're doing a something like jplayer should handle the
> streaming to most HTML5 browsers.
>
> Another option in your case is to upload the content to Youtube
> and link to it. Youtube takes care of transcoding and streaming
> to different devices.
>
> Steve
>
I haven't listened to anything from the web in years. I had made
an unrecognized assumption - that one downloaded then listened.
Hadn't thought about streaming.
Reply by Marcel Mueller●September 24, 20162016-09-24
On 23.09.16 22.13, Richard Owlett wrote:
> Notice I've deleted all replies? <chuckle>
> Though deleted, they have educated me ;> !!
>
> The "answer" [please note quotation marks] *AS ASKED* legitimately range
> from
> less than "1 MB /sec" to ">3 MB /sec".
> This leads to multiple questions:
> 1. Does a host care how an audio file is encoded?
No. It just provides some binary data.
> 2. What encoding can a modern browser handle transparently?
You should use the HTML 5 <audio> tag nowadays. It supports MPEG-1 Layer
3 (aka MP3) and Ogg-Vorbis as compressed formats.
However, Microsoft and Apple refuse to support Ogg-Vorbis even though it
is free. So you are stuck with MP3 in this case. This will play
seamlessly in all modern browsers and operating systems, including the
very old one that I am currently using.
Use LAME as MP3 encoder. It is free, it is the best.
For music (including chorus) I recommend the setting "--preset standard"
For speech you might look in the net for better presets. E.g. something
like "-m m -v --lowpass 14 --highpass .1 --highpass-width .03" The
latter options discard rumbling noise on the fly.
Marcel
Reply by ●September 23, 20162016-09-23
On Fri, 23 Sep 2016 15:13:40 -0500, Richard Owlett
<rowlett@cloud85.net> wrote:
>Notice I've deleted all replies? <chuckle>
This is usenet. Nothing got deleted. It's all still there,
archived forever.
>Though deleted, they have educated me ;> !!
>
>The "answer" [please note quotation marks] *AS ASKED*
>legitimately range from
>less than "1 MB /sec" to ">3 MB /sec".
>
>This leads to multiple questions:
> 1. Does a host care how an audio file is encoded?
What sort of host are you talking about? The mission and resources
of the server may dictate what tradeoffs make the most sense for a
particular context.
> 2. What encoding can a modern browser handle transparently?
> [The last time I retrieved an audio file was when dial-up
>was SOP ;]
>
>Assume I'm totally ignorant. A certain resident on PLUG might
>cheerfully certify same.
Reply by Steve Pope●September 23, 20162016-09-23
Richard Owlett <rowlett@cloud85.net> wrote:
>Notice I've deleted all replies? <chuckle>
>Though deleted, they have educated me ;> !!
>
>The "answer" [please note quotation marks] *AS ASKED*
>legitimately range from
>less than "1 MB /sec" to ">3 MB /sec".
>
>This leads to multiple questions:
> 1. Does a host care how an audio file is encoded?
> 2. What encoding can a modern browser handle transparently?
Unfortunately, assuming you want to support PC's, MAC's, and
both Apple and Android mobile devices, and you want this
to stream on all these devices (as opposed to, or in addition to, allowing
file download), you're going to have to support several filetypes
and possibly embed a player such a jplayer into your website.
A typical Android phone with no extra apps installed will not
stream audio from a typical audio-streaming website, even when
it's an mp3 stream. (This deficiency creates an entire business model
for Tunein, a startup out of San Francisco, which basically is paid by
broadcasters to create a website/app combination that reliably streams.)
For what you're doing a something like jplayer should handle the
streaming to most HTML5 browsers.
Another option in your case is to upload the content to Youtube
and link to it. Youtube takes care of transcoding and streaming
to different devices.
Steve
>>The goal of this genre of music is to immerse yourself in it, any
>>artifacts will detract.
>Only if those artifacts are discernible to the listener. Dropouts
>from the any portion of the link not being able to continuously
>support the rate are generally far more annoying than compression
>artifacts. Pick your tradeoffs wisely.
Which is why I wrote in my first post to this thread, "You might consider
giving listeners a choice of that [320 kbps], or a slower rate such as
128 kbps, since their feed may be slow."
Selecting at semi-random a site I often listen to, KALX that being
U. C. Berkeley's radio station, they have four streams: Ogg at 128 kbps,
and MP3 at 128k, 56k, and 24k mono.
Steve
Reply by Richard Owlett●September 23, 20162016-09-23
Notice I've deleted all replies? <chuckle>
Though deleted, they have educated me ;> !!
The "answer" [please note quotation marks] *AS ASKED*
legitimately range from
less than "1 MB /sec" to ">3 MB /sec".
This leads to multiple questions:
1. Does a host care how an audio file is encoded?
2. What encoding can a modern browser handle transparently?
[The last time I retrieved an audio file was when dial-up
was SOP ;]
Assume I'm totally ignorant. A certain resident on PLUG might
cheerfully certify same.