transcoder order

[slartibartfast]

I have modified my copy of Spotty's custom-convert.conf to test this spt-flac transcoding rule, currently playing using slimserver 8.2. So far so good.

Happy New Year!

Did you find any 48kHz tracks?

Sent from my Pixel 3a using Tapatalk

[Ron F.]

Did you find any 48kHz tracks?

Sent from my Pixel 3a using Tapatalk

No, I have not been looking; I simply read that labels and artists can submit content in 48 KHz, that they are not restricted to 44.1 KHz. I will spend some time tomorrow looking for evidence of this. It is very reasonable to hold this as suspect. The most likely material however, I imagine, would be motion picture related content.

Upon reading this, I thought that hard-coded sample-rate/bit-depth rules, like Spotty's current spt->flac rule, are probably not a good idea in general.

[Ron F.]

I'm trying to work on that to have the librespot maintainer include that option natively so that Michael does not have too much backporting to do, but that's my first steps with Rust and oh boy, what a nightmare

Rust. It seems that languages today are breeding like rabbits, and often don't last much longer.

My past experience, is that you have to put a good fifty thousand lines behind you, before you REALLY know a new language. After my first five thousand lines in Python, I thought I knew what I was doing ... it was so easy. Then after my next five thousand lines, I went back and began to refactor my first five thousand lines. Oh my God; what had I been thinking?

Good luck with Rust Philippe!

[philippe_44]

Rust. It seems that languages today are breeding like rabbits, and often don't last much longer.

My past experience, is that you have to put a good fifty thousand lines behind you, before you REALLY know a new language. After my first five thousand lines in Python, I thought I knew what I was doing ... it was so easy. Then after my next five thousand lines, I went back and began to refactor my first five thousand lines. Oh my God; what had I been thinking?

Good luck with Rust Philippe!

Totally, but I feel Rust is a very special animal. I'm not going to pretend I'm good at learning new languages (because I'm really not), but Rust is what I would call a "totalitarianism" in a sense that most of languages have similar concepts and (most important) allow you to progress step by step. Yes, you make tons of silly mistakes at the beginning but you grow your knowledge (especially on the new concepts) at your own pace.

Rust does not seem to be like that. There is no "simple" app to start with. Very quickly, it wants you to be "all in" and you have to understand all its concepts (and it has many) to build even the simplest application. In addition, the syntax looks like it's trying to bite (snap) you all the time. Anyway ... at least, learning something is good

[mherger]

> There might be another issue here, and this might just be rumor/myth,
> but I have read that Spotify can stream both 44.1 and 48 KHz sample rate
> content in it's 320 kbps stream.

When googling this topic you'd find a log of question, and little to no
answers. What I did find though was mention that as an
artist/label/whoever is delivering the content can do so in 44.1kHz or
48khz. But that everything would be normalized to 44.1kHz on Spotify's
end. Add to this the fact that there's been no feedback I can remember
which sounded like using wrong sample rate or something. Streams not
playing to the end etc., yes, but that doesn't sound like 44.1 vs. 48kHz.

--

Michael

[slartibartfast]

No, I have not been looking; I simply read that labels and artists can submit content in 48 KHz, that they are not restricted to 44.1 KHz. I will spend some time tomorrow looking for evidence of this. It is very reasonable to hold this as suspect. The most likely material however, I imagine, would be motion picture related content.

Upon reading this, I thought that hard-coded sample-rate/bit-depth rules, like Spotty's current spt->flac rule, are probably not a good idea in general.

I have also seen forum posts elsewhere mentioning that some tracks are available at 48kHz but not a single example is ever posted. I thought I had found an example in one post but it doesn't seem to exist on Spotify.

Sent from my Pixel 3a using Tapatalk

[mherger]

> Because what is sent to the flac encoder is raw data, so it does not
> know how to interpret it and needs a bit of help. When spt-pcm is used,
> LMS tells the player what is sample rate and size.

Correct.

> Now, the good news is that with the latest PR in 8.1, Michael, we know

Haha... you'd think I knew, yes :-D.

> now the source sample rate, size & channels as we needed that for smart
> transcode

But that's 8.1 only. I don't know why I should optimize things for 8.1
when there's no problem to solve...

--

Michael

[philippe_44]

> Because what is sent to the flac encoder is raw data, so it does not
> know how to interpret it and needs a bit of help. When spt-pcm is used,
> LMS tells the player what is sample rate and size.

Correct.

> Now, the good news is that with the latest PR in 8.1, Michael, we know

Haha... you'd think I knew, yes :-D.

> now the source sample rate, size & channels as we needed that for smart
> transcode

But that's 8.1 only. I don't know why I should optimize things for 8.1
when there's no problem to solve...

--

Michael

Yes, that's right, that would only be a 8.1 solution and making the plugin version-aware seems like an un-necessary complication if Spotify is 44.1k

[FatPete]

In fact, thinking about it again, there is simple option for the "native" format first: adding an option to the "File Types" settings (which is not very used anyway) that says "Prioritize native format" and when it is set, all I do is put at the top of the profiles list the input format.

	@supportedformats = Slim::Player::CapabilitiesHelper::supportedFormats($client);

Re-order that list to put the "$type" codec (if exist) at the top. I would not make that player specific, just a general server option.

This is a really nice change to LMS - thanks! I've been running your uPnPBridge for ages now on LMS 7.9 and never quite understood why LMS always felt it was necessary to convert my flac files to PCM/WAV rather than sending natively. Last night I finally got round to using the new official Docker container for LMS 8.1, and was then puzzled as to why it was now sending flac natively when my configuration was identical to my old 7.9 install. Didn't really understand what was going on until I compared the "Advanced --> File Types" pages in 7.9 and 8.1 and saw the new "Prefer native format (decoding on the player) whenever possible" setting. Thanks again for implementing it