Azuracast: Option to stream in 43.2Khz sampole rate instead of 44.1Khz?

[joaoherberto]

I am currently using Libretime for a station and am thinking of switching to Azuracast, but I was wondering if there is an option or the ability to stream in the 43.2Khz sample rate instead of the standard 44.1Khz?

[SlvrEagle23]

@joaoherberto I'll flag this as an enhancement request, but I'll be honest...in my many years of working on AzuraCast, this is honestly the first time this request has ever come up.

Looking up the background of popular sampling rates, I can't seem to find anything about 43.2Khz that doesn't lead me to believe this request may be a joke.

What's the reasoning for that specific number?

[joaoherberto]

I assure you it is not a hoax, 43.2khz is the natural resonance/ frequency of human hearing. It used to be the standard before the mid 1930's. Then for what appears to be no reason, it was standardized to 44.1. all you have to do is encode some music at 43.2 and you will feel the difference. Research it for yourself, I myself have converted all my audio to 43.2 and will never go back.

[interru]

As far as I can tell: Thats seems extremely esoteric. The only thing you are introducing with this is a little bit of noise (which you can't really hear) because your sound card most likely doesn't operate with 43.2khz which means your audio subsystem has to convert the audio back to 48khz (which is often the default sample rate on most cards).

Also I doubt that they had digital encoded audio in mid 1930's which required some kind of sampling.
What you are probably confusing is pitch standards: https://en.wikipedia.org/wiki/Scientific_pitch (432 hertz)
And at what pitch music is recorded has nothing to do with the sampling rate as long as the frequency is under the nyquist frequency ( https://en.wikipedia.org/wiki/Nyquist_frequency )

An explanation how digital audio works is explained here: https://people.xiph.org/~xiphmont/demo/neil-young.html
This video also does a really good job at explaining this: https://xiph.org/video/vid2.shtml

[SlvrEagle23]

@joaoherberto Can you tell me more about how Libretime is handling this currently? Is it a selection of preset sampling rates, or just an open text field that you can specify any sampling rate in?

It's entirely possible that we could implement the latter.

[interru]

While I certainly don't want to take peoples freedom to do stupid things but streaming with something different than 44100 or 48000 hertz doesn't make any sense! It'll cause playback problems for small low powered devices with no benefits whatsoever.

There is a reason why codecs like opus (which is fairly new) limits the sample rates to a selection of 5.

So my question would be: Why? I currently don't see any use case except for someone who wants to shoot himself in the foot without knowing the implications and consequences.

[joaoherberto]

My apologies for lagging in response to the feedback, I have just ben really busy. There is a misconception about the reasons I would want to stream in 43200 and not 44100. Although Interru may feel it is rather esoteric, that is, with all due respect, a subjective opinion. Objectively speaking I can play two identical pieces of music, one in 43200 and one 44100, the difference is tangible, there is a difference, a very noticeable difference. I have put together a test page, https://www.latinritemass.net/assets/radio.html 43200 files play just fine with HTML audio tags, most players can also play 43200 sample rates, if they cannot, it is because they have chosen to block it.
MP3 file formats only support 44100, ogg does support 43200 and lowering the sample rate can only be a benefit in streaming.

I did find that in Icecast Docs, there is an option for re-sampling the bitrate http://icecast.org/ices/docs/ices-2.0.2/config.html

The kind of audio I am streaming would benefit from 43200, I would at the very least like to offer it on just the ogg stream.

I have completely switched my streaming from Libretime to Azuracast, and I have to say, it works extremely well! I will focus on supporting Azuracast where I can moving forward.

[interru]

Although Interru may feel it is rather esoteric, that is, with all due respect, a subjective opinion.

I don't "feel" it's esoteric. I know it's esoteric! And I provided resources to show you the theorems on which I base my current understanding. I am completely open to change my mind if you find something with substance which falsifies my views. This at least satisfies my subjective definition of objectivity.

Objectively speaking I can play two identical pieces of music, one in 43200 and one 44100, the difference is tangible, there is a difference, a very noticeable difference. I have put together a test page, https://www.latinritemass.net/assets/radio.html 43200

You are comparing:

• mp3 to ogg
• 43200 to 44100
• With a single A-B test which ignores human psychology (placebo effect)
• No mention of the source material
• I compared the files in my DAW:
  
  
  
  • The ogg file has a glitch at the start ( https://imgur.com/a/0rUehfs ) which leads me to question the quality of the whole file.
  
  
  • I inverted the phase of one file to get the difference (after aligning (precisely) because of the glitch in the ogg file) and yes you can hear that. But that happens if you have 100 factors which you didn't exclude out of the equation. (Which is very unscientific)
  
  

if they cannot, it is because they have chosen to block it.

Most audio subsystem resample weird sample rates. The resample process as I have said introduces noise and is cpu expensive. In pulseaudio for example the better algorithms (You can choose between 20 variants of speex, ffmpeg, peaks and soxr) can easily utilize half of a cpu core.

43200 and lowering the sample rate can only be a benefit in streaming.

What is it about this number that it makes you think it's perfect for music. Did you try other sample rates? Have you tested 1000 for example? ;)

[joaoherberto]

I don't understand the visceral reaction to this simple request for an option, I will just keep my esoteric questions to myself.

[interru]

Just for record: I am not associated with this project and I haven't contributed as of now. I am just a single lonely developer who thinks that this idea is counterproductive for the reasons I mentioned above.

[SlvrEagle23]

I don't ever want someone to close an issue out of feeling that the response to it was too hostile or negative. That's not how we operate on this project.

@joaoherberto Your original request for an option to specify a custom sampling rate is not only reasonable, it's quite simple to implement, as this is a single parameter that we provide to Liquidsoap when transcoding audio. We hard-code it to 44.1khz now, but we could use different sampling rates with little issue. Just out of curiosity, what other sampling rates does Airtime include on their software? It may be a valuable reference.

@interru While some of your commentary in this thread has been accurate and legitimate, you should bear in mind that your commentary doesn't reflect the priorities that AzuraCast will adopt as a project. At its core, this request is indeed a benign one for an added configuration option that corresponds directly to something we use under the hood, and interactions in our GitHub should always adhere to the high standards of our Code of Conduct.

[interru]

While _some_ of your commentary in this thread has been accurate and legitimate

What wasn't accurate/legitimate?

and interactions in our GitHub should always adhere to the high standards of our Code of Conduct.

This implies my interactions didn't adhere to the Code of Conduct. What exactly? I might learn something because currently I don't see how I should have handled this differently. The only thing I could have done is sugar coat my responses. But that wouldn't help anybody.

[SlvrEagle23]

@interru The issue was more with statements like "...I certainly don't want to take peoples freedom to do stupid thing...", which is inherently subjective and not a respectful interaction. I don't want to devolve into the minutiae about whether such a thing "should be" offensive or not; it could've been worded better.

From my research, where you are accurate is that the vast majority of research I can find on this subject matter strongly suggests that the 43.2KHz preference is largely based on pseudoscientific claims. Moreover, it is also accurate to suggest that a vast majority of sound playback devices will simply resample any incoming audio, largely negating any prospective benefit this may offer.

Nonetheless, the option of having a custom sampling rate is a fine one, and if it costs us effectively nothing to just add the 43.2 KHz option as one of many selectable sampling rates, I'm okay with this, due in large part to the established precedent of other web radio management suites offering it as a selectable option.

[interru]

Subjective and objective are not exclusive and subjective statements are not inherently bad. If I say a view/opinion is stupid then that is a subjective statement which can be followed/preceded by an objective reasoning. It also reflects my feelings towards the discussed subject and I really don't like to sugar coat that. I never said anything on the personal level against him and only focused on the idea itself!

This sentence/comment was btw. intended to be read like this: "People are free to do things which are counterproductive but you don't need to help them to do that.". Could have been worded better.

and if it costs us effectively nothing to just add the 43.2 KHz option as one of many selectable sampling rates

Doesn't cost this project anything. But I don't like the idea of including an option which would only decrease listener experience.

[joaoherberto]

@SlvrEagle23 I could not find the option in Libretime and I have switched to Azuracast now, so I deleted that server. In researching the topic, I remember the only thing I could find was to manually add the code to Icecast XML file in Icecast 1.x.

I am only going to touch on the subject one more time... the 43.2Kz was established as a standard in 1881, In Italy... Many tuning forks from the 1800's that exist today were tuned to right around the 432 435 hertz. Historically, the majority of records sold in the US up until 1939 were in 43.2Khz. Even in my area, Craigslist often has ads for pianos for sale with prominent notation that the piano was recently tuned to the 43.2Khz.

As I have researched this topic, I have learned that there is mathematical formula for how the musicians at the time came up with the standard, it has to do with the middle C as a base and then running through the octaves, which for the A440 standard, it has all of the implications of being an arbitrary number with no real reason as to why.

At any rate, the project I am working on is to have two streams, one for music using the 432 and one for talk using the A440.

This will be my last post on this thread, there is no ill feeling towards anyone. If the option can be added, I would like to use it if not, I will let the project owner know. In the mean time, I like how Azuracast is implemented and look forward to helping in any way I can.

Here is a link that has some interesting info for the curious.
Link

[CodeSteele]

Yeah, while some discussion has been happening here @SlvrEagle23 and myself have been bouncing back and forth at the "larger picture" issue of controlling the sampling rate.

and if it costs us effectively nothing to just add the 43.2 KHz option as one of many selectable sampling rates

We had been discussing this off and on a bit -- is there any value just making this free-form? I would imagine if you had an entire library sampled at a different rate it would be a lot easier on LiquidSoap to not have to re-sample it, right? (Considering LiquidSoap seems to be one of our biggest CPU-time eaters).

[SlvrEagle23]

@CodeSteele with regard to lightening CPU load, I'm pretty sure that no matter what you do, Liquidsoap will always use fairly constant CPU resources, as it's decoding the content of the music in order to apply amplification gains, crossfades, etc. to it, then encoding the resulting muxed signal back again.

[SlvrEagle23]

We're migrating our feature requests over to FeatureUpvote, which allows users to vote on what they would like to see the most, and helps clear our GitHub issues page up for bugs and error reports.

Your enhancement request has been migrated over to FeatureUpvote and can be found here:
https://azuracast.featureupvote.com/suggestions/39032/support-custom-sample-rates