| Issue 73: | play after rip | |
| 2 people starred this issue and may be notified of changes. | Back to list |
OK, I was reading the "no sound" issue and came up with some other ideas to "enhance" theLastRipper, but still keep it true to it's primary objective, to rip last.fm mp3s :) I was going to post this to that issue, but figured I'd jot the ideas down in a new thread instead. In a way, I can understand not letting the tracks be listened to, keep the program simple and to it's point "ripping" :) On the other hand, a "play after rip" feature would be great, as it would elimnate the "buffering" experience often associated with "streaming" content over the Internet, it could also eliminate the "up and down" music volumes, that some user(s) report on the last.fm forums -- since most common audio players nowadays have a volume normalizer/replaygain feature of some sort built into the player. One problem I've seen though, is tracks I don't want downloaded and/or scrobbled to your account will get tallied up, because you won't actually "hear" them until they are already tallied into your profile; making it a chore for people to remove tracks from their accounts that they do not want. mmm...then a feature request/idea :) Allow an artist "filter"? Say, a "blocklist" of sorts. That would stop theLastRipper from "scrobbling" or downloading certain tracks by certain artists. So basically, I could tune in to the "rock" tag, set the lastripper to not rip NOR scrobble artists: Ja Rule, Ashlee Simpson, Avril Lavigne (y'know, cause that's not really "rock", but people on last.fm like tagging stuff weird :P) Obviously, the player could still "play" the track (or if the user notices it playing, they could skip it...either way) but having the option to not scrobble or not Download...or even Scrobble, but not Download (maybe they already have that artists mp3s on their hard drive or whatever, but still would like the artist track to be submitted to their profile) Though I don't know how in depth the team wants to go with the project ;) |
|
,
Sep 16, 2007
Like you say: Most people wants playback because it would enable them to skip song they don't like... That's what I've heard from countless users. But I think it's could be possible to fix this issue by implementing issue 15 . You suggest blacklisting, that solution would never work completely, since you can't blacklist everything you don't want :) Furthermore, I think it's important to make sure TheLastRipper is "an opensource audio stream ripper for last.fm", not "last.fm ripper". If you look at the unofficial documentation of Last.fm protocol version 1.2 in our wiki, you'll see that thís new protocol could be abused, very easily. I don't think we want to do that. Features like blacklisting, autoskip etc. are kind of moral dilemmas to me, I think I'll create an open discussion for these topics, once we've got an implementation of the last.fm protocol version 1.2. Anyway, playback after rip isn't a bad idea... But it would probably require somekind of interfacing with the default mediaplayer. I know there's a dbus specification for Linux audio players in the workings (don't know the current status). But how could I interface a generic audio player on Windows or OS X? I assume you want to add newly recorded tracks to the playlist of the users audioplayer of choice. |
|
,
Sep 16, 2007
I dont see a problem with a blocklist. It would not go against the protocol, obviously thelastripper would still spin the tracks as the last.fm streaming server sends them over, but the "feature" I was outlining (the blocklist) would stop the track from being downloaded if it was a track from an artist they do not want downloaded. I'm not suggesting any sort of "auto-skip" feature as that would definately be against the protocol...I was only suggesting a way to not allow file downloads of certain artists (since one can view the tag/artist cloud before jumping into a radio station to see probable streaming artists). Last.fm already allows removing recent plays, the suggesting of removing "blocklisted" artists from recent plays was just a suggestion. |
|
,
Sep 17, 2007
(No comment was entered for this change.)
Status: Wishlist
|
|
,
Feb 25, 2008
"play after rip" wuold be a great feature, and it's quite easy to do,
just adding a modifiable command that adds the last ripped mp3 to a player queue.
for winamp: winamp /add "path to file"
for amarok: dcop amarok playlist addMedia("path to file")
and I think that for other players will be a command that do so.
|
|
,
Feb 25, 2008
I think dcop is being depreached with 4.x of KDE |
|
,
Feb 25, 2008
By the way I remember look into some dbus unified specification for all media players... but I don't think it's been implemented yet... But enabling people to execute a command after each songs been download shouldn't too hard... this would also be a nice solution to adding replaygain.. |
|
,
Apr 09, 2008
Three words: embedded stream server. Would be fantastic to be able to rate as you rip. Or rather, rip as you play. And PLEASE, if this ever comes to be, add a hook to the "forward/next" "multimedia-button" on new keyboards, and also some other hotkey button tag the song with a predefined tag (or stick it to loved) (maybe the "back"-button can be used, since that doesn't make sense with last.fm). |
|
 Sign in to add a comment
|
