Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • 13:52
    Groovylein closed #829
  • 13:52
    Groovylein opened #829
  • Aug 02 18:00
    capnfabs opened #828
  • Jul 30 12:36
    ashthespy labeled #826
  • Jul 30 12:28
    regie-techno edited #826
  • Jul 30 12:28
    regie-techno edited #826
  • Jul 30 12:27
    regie-techno opened #826
  • Jul 26 18:45
    JasonLG1979 synchronize #820
  • Jul 25 19:10
    JasonLG1979 synchronize #823
  • Jul 25 18:36
    JasonLG1979 synchronize #823
  • Jul 25 02:17
    JasonLG1979 synchronize #823
  • Jul 24 20:44
    JasonLG1979 synchronize #823
  • Jul 24 18:36
    JasonLG1979 commented #823
  • Jul 24 18:09
    JasonLG1979 synchronize #823
  • Jul 24 17:59
    JasonLG1979 synchronize #823
  • Jul 24 17:30
    JasonLG1979 edited #823
  • Jul 24 17:29
    JasonLG1979 synchronize #823
  • Jul 24 16:56
    JasonLG1979 edited #823
  • Jul 24 16:53
    JasonLG1979 synchronize #823
  • Jul 24 16:37
    JasonLG1979 synchronize #823
Roderick van Domburg
@roderickvd
-2 dBFS would arguably be better to prevent intersample peaks but if that were the goal, then the threshold should be at -3.2 dBFS or thereabouts, depending on who you ask.
Jason Gray
@JasonLG1979
It seems that they've changed everything to LUFS also at https://artists.spotify.com/help/article/loudness-normalization
If the limiter threshold has changed to -2 dBFS then I think we should follow suit don't you?
Jason Gray
@JasonLG1979

-2 dBFS would arguably be better to prevent intersample peaks but if that were the goal, then the threshold should be at -3.2 dBFS or thereabouts, depending on who you ask.

Intersample peaks are a bad thing for sure but it's a bit of fool's errand to chase them in librespot as it's highly dependent on hardware, what happens to the audio after librespot and how the songs was mastered. In an objectively perfect world with a well mastered song, clean digital signal path, and good hardware intersample peaks wouldn't happen and everything would sound amazing. In the worst case everything clips horribly all the time and sounds like garbage all the time. Reality is somewhere in the middle, again depending on variables outside of the control of librespot. Then there's the matter of the fact that the limiter itself will introduce some distortion the more you smash the audio.

Jason Gray
@JasonLG1979
Not to mention the fact that your limiter can't actually even detect intersample peaks. By definition they happen in between samples and are only detectable if you oversample by a crap ton (even then it's not perfect) or if you analyze the analog output. That -3.5 number is just a guess based on what people have seen in the wild. What that means is that if you reduce the gain of everything by -3.5 you'll most likely not get very many intersample peaks. By that logic you would set your full volume to -3.5 and not use any volume normalization at all if you were so concerned with (more than likely inaudible) intersample peaks. A non-oversampling digital limiter does you no good.
Roderick van Domburg
@roderickvd
All true on the intersample peaks.
As for -2 dBFS, I'm not sure, it's just guessing from that account_attributes response. I don't have the golden ear to discern -1 from -2 dBFS. However, 0/+3 dB should be audible for Normal and certainly -5/-9 dB for Quiet. Should do some listening tests.
Jason Gray
@JasonLG1979

As for -2 dBFS, I'm not sure, it's just guessing from that account_attributes response. I don't have the golden ear to discern -1 from -2 dBFS. However, 0/+3 dB should be audible for Normal and certainly -5/-9 dB for Quiet. Should do some listening tests.

Those were the stated values when the loudness-normalization page stated things in dB's if I remember correctly. It could very well have changed? At the time when you 1st wrote the dynamic normalization bits I did some quick listening tests between librespot and the official Spotify desktop app and it seemed to line up about right but I didn't break out a decibel meter or anything and I don't claim to have "Golden Ears" either.

Jason Gray
@JasonLG1979
In my, again very unscientific tests, "Loud" in the app sounds like squashed hot garbage and "Quiet" sounds, well, just too quiet. Even "Normal" can sound a little bit squashed depending on the track. I would say that -3 to +3 is basically the usable range IMHO.
Jason Gray
@JasonLG1979
OK @roderickvd apparently LUFS is equal to dBFS, (I did not know that. You may already have?) according to this: https://www.tcelectronic.com/loudness-explained.html, so Spotify using LUFS doesn't really effect us at all really. -2 LUFS is the same as -2 dBFS so the math doesn't change so long as they still use the replay ReplayGain standard to generate the values. If they start to use some unknown, non-standard method for determining the apparent volume of a track then we're in trouble.
Roderick van Domburg
@roderickvd
Yes, previously it used to be Quiet: -5; Normal: +3; Loud: +6. What's usable depends on the headroom in your amp. I like to run on quiet and dial my amp up (actually: drop the attenuation). But I digress, if we want to check if my interpretation of Spotify's latest response is right then we should compare loudness of the pregain (not threshold).
Roderick van Domburg
@roderickvd
LUFS isn't dBFS because LUFS is k-weighted (although 1 LU is like 1 dB in the sense that it is dimensionless, so you can do -10 LUFS - 1 LU = -11 LUFS and -10 dBFS - 1 dB = -11 dBFS but you can't mix up the units). When I said it was somewhat opaque, that wasn't very specific. On the one hand, LUFS is standardised (which is nice) but doing volume control in LUFS scale, well, that's almost impossible on the fly due to the weighting and averaging. I suspect Spotify doesn't do normalisation in LUFS either; it might master to a target LUFS but then still normalise in dBFS during playback.
Michael Herger
@michaelherger
QQ: is the mixer command line argument even still supported? I don't see it evaluated anywhere in main.rs.
Michael Herger
@michaelherger
Roderick van Domburg
@roderickvd
You're right, this is a bug that's caused by incorrectly merging two diverging branches. Those lines I referenced should read MIXER and not MIXER_NAME.
Linus Torvalds
@doomslayer117:matrix.org
[m]
Hey guys
quick question
how does the decryption part work?
because in theory it has to fully emulate widevine l3 so it can get the AES keys to decrypt the song blobs
Nick Steel
@kingosticks
No. Spotify only use widevine in the webplayer. Their "native" clients use a simpler scheme. Which is what librespot (and friends) implement.
Linus Torvalds
@doomslayer117:matrix.org
[m]
Oh right thanks
Linus Torvalds
@doomslayer117:matrix.org
[m]
thanks dudes then
Just finished dumping audio and making it work for non premium accounts
its basically ytdl for spotify now lmao
Nick Steel
@kingosticks
That's not a helpful thing to do. Please don't do that.
Or at least don't distribute it.
1 reply
devgianlu
@devgianlu
Yep, I'm with @kingosticks
Roderick van Domburg
@roderickvd
Indeed we don't condone and highly discourage that.
Roderick van Domburg
@roderickvd
@michaelherger if you could check librespot-org/librespot#821 w.r.t. the Alsa mixer? It's working again on my end.
Michael Herger
@michaelherger
I'm only using the pipe backend... I was only wondering about the --mixer parameter as I'm using a customized build, and I wanted to get rid of any unused (in my implementation) parameter.
I quickly skimmed your change: wouldn't mixer-name be obsolete now?
mixer-name is the name of the Alsa control. It would have been less confusing if it would have been called mixer-control from the beginning, but alas it hasn't and I think we should now stick with it.
Michael Herger
@michaelherger
Gotcha, thanks!
Ash
@ashthespy

mixer-name is the name of the Alsa control. It would have been less confusing if it would have been called mixer-control from the beginning, but alas it hasn't and I think we should now stick with it.

That would be a relic from my initial implementation ;-) Please feel free to change this to reflect proper convention..

Roderick van Domburg
@roderickvd
Considering this is already in the wild I think it's fine to keep it as-is and retain stability in the command line options.
Jason Gray
@JasonLG1979

mixer-name is the name of the Alsa control. It would have been less confusing if it would have been called mixer-control from the beginning, but alas it hasn't and I think we should now stick with it.

If it's ALSA specific and doesn't do anything on any other backend (?) it should be called alsa-volume-control-name or maybe alsa-volume-mixer-name idk? At least something that makes it more clear what it is and that it's ALSA specific. Leading up to 0.3 the theme seems to be not being afraid to break things, so long as it's on purpose, documented and an improvement, ofc,lol!!!. Clarifying ambiguous arg names seems like an improvement to me. Plus it's not like there was ever any promise of API/arg name stability in the 1st place.

Nick Steel
@kingosticks
You could add mixer-control (or whatever) and print a warning when mixer-name is used, stating that it is now deprecated and will be removed soon (i.e. In a version after the next released version). It's nice to avoid breaking changes when it's cheap to do so.
Roderick van Domburg
@roderickvd
That's all true and worth considering.
Ash
@ashthespy
Probably best to align to mpd as @kingosticks suggested back then..
But yeah, low priority so lets switch it the next time someone is in there...
Ghost
@ghost~60fe79bf6da037398481d599
hey, did anyone create a c# version of librespot?
Tony
@TonerK7_twitter
anyone here know what the fields "server_signature_key" & "gs_signature" are
in LoginCryptoDiffieHellmanChallenge (in keyexchange.proto)
SuisChan
@SuisChan_gitlab

anyone here know what the fields "server_signature_key" & "gs_signature" are
in LoginCryptoDiffieHellmanChallenge (in keyexchange.proto)

https://github.com/librespot-org/librespot/discussions/641
librespot-org/librespot-java@aa17da7

Tony
@TonerK7_twitter
thank you
Johannesd3
@Johannesd3
Could someone please tell me what happened the last one/two months in librespot while I wasn't able to follow everything?
Xavier
@dempzh_twitter
Hey, does anyone of you have worked on a mitm for the android/ios app for the tcp socket ?
SuisChan
@SuisChan_gitlab

Hey, does anyone of you have worked on a mitm for the android/ios app for the tcp socket ?

Yes, but sometimes it works very unstable, due to my poor implementation
(

Xavier
@dempzh_twitter
I sended you a pm :D