Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Hacky solution for more automatic/accurate track separation #4

Closed
cgarz opened this issue Nov 1, 2018 · 8 comments
Closed

Hacky solution for more automatic/accurate track separation #4

cgarz opened this issue Nov 1, 2018 · 8 comments
Labels
enhancement New feature or request

Comments

@cgarz
Copy link

cgarz commented Nov 1, 2018

To allow greater automation for people who want to just set it and go, like myself. It's possible to make a playlist of all the songs you want with a silent track separating them.

You could then have an optional mode where you would read this as an end of track message and close ffmpeg.

This would also eliminate the pause > previous > play commands between each song. Simply start the next recording then send the next song command.

A nice 10 second example titled "Silent Track" from artist "Silent Track" is here:
http://open.spotify.com/track/5XSKC4d0y0DfcGbvDOiL93?si=V6UuIOkYRl2XrJOzhVHlIA

However, since this would then just shift the tedium from post processing to playlist creation, I've found a lovely playlist creator with conditionals, combiners and other goodies:
http://smarterplaylists.playlistmachinery.com/examples.html

I created a massive playlist of the silent track by continually copying its tracks into itself. I stopped at 8192. Then I used the "alternate" combiner to combine that playlist with my saved tracks. It stops once one list is exhausted. When run, it quickly spits out a nice silence gapped playlist =D.

What do you think?

@Bleuzen
Copy link
Owner

Bleuzen commented Nov 3, 2018

This would not work, because it is not possible for us to guess the next song.
To start a new recording, we need the song name. We can only get the current playing songs name. So SpotRec would have to wait until next song starts playing to detect it's name.
Since there is a little delay after song name detection, SpotRec goes to the beginning of the song again to not miss the first second in the recording.
Currently the only way to go to the beginning is to pause and previous. No other way we could use rn.
So this would not eliminate the need of this.
-> Would make no sense to implement.

@Bleuzen Bleuzen closed this as completed Nov 3, 2018
@cgarz
Copy link
Author

cgarz commented Nov 3, 2018

Ah yes that would be another issue. SpotRec would need to write to a temp file and rename once done.
Is that out of the question? If so, why?

@Bleuzen
Copy link
Owner

Bleuzen commented Nov 3, 2018

Not sure what it has to do with this, but to write to a temporary hidden file is already supported.
Just pass -t as argument when starting SpotRec.

@cgarz
Copy link
Author

cgarz commented Nov 3, 2018

Yes I saw that thanks. I actually enabled that option since I preferred it.

Sorry I'm still being unclear, what I mean in this case is that the temp file would no longer have the <trackName>.flac format and would instead have a <GenericName>.flac format. Then after recording is done you would rename the <GenericName>.flac to <trackName>.flac

The process would be as follows:

  • SpotRec loaded with an option that enables this alternative silent track method.
  • SpotRec would then switch from using the track name for ffmpeg to using a generic name.
    (Example: SpotRec.tmp.flac)
  • SpotRec starts recording the track to SpotRec.tmp.flac
    (At this point the track is the silent track, no name is known.)
  • SpotRec sends the next track command
  • SpotRec can now get the track name, stores it for later renaming
  • Once the track is finished. Silent track begins playing again
  • SpotRec notices this. Finishes the recording
  • SpotRec then renames SpotRec.tmp.flac to <trackName>.flac
    (or whatever the user wants the format to be)
  • Then the process can repeat.

In this way entire playlists or saved track collections can be reliably recorded and will at worst contain a tiny bit of leading/trailing silence. Which is much easier to remove programatically in a batch process if needed.

@Bleuzen
Copy link
Owner

Bleuzen commented Nov 3, 2018

Yeah would be possible.
But not today or tomorrow, because:

  • Is this useful? How many users would benefit from it? Is it worth the time to implement? Or would it just blow the script up to much?
  • I have limited time and other projects and real life things going on, I won't do it in the near future. But it may be a good idea for some free days or a pull request.

@Bleuzen Bleuzen reopened this Nov 3, 2018
@Bleuzen Bleuzen added the enhancement New feature or request label Nov 3, 2018
@cgarz
Copy link
Author

cgarz commented Nov 3, 2018

I understand, it is a pretty niche thing with alot of setup required. I might try to make it myself to get all my saved songs. I'm not a great programmer though so it would probably be ugly.

Any suggestions how best to do it? For example where should I put the track info query and the renaming part?

@Bleuzen
Copy link
Owner

Bleuzen commented Feb 27, 2019

Hi, sorry for not answering, I missed your last message somehow.
I will close this issue because nobody seems interrested in doing this. (You may still do it if you want.)

As a hint: If you want to listen to track changes, implement your code in the "playing_song_changed" method of the "Spotify" class. In this method you have acces to the new song (as shown in the log message there). You can use it to detect if it is the silent track.

@Bleuzen Bleuzen closed this as completed Feb 27, 2019
@cgarz
Copy link
Author

cgarz commented Feb 27, 2019

No worries I've been working on other things so didn't have a chance to try this yet anyway.

I would still like to try it though so thanks for the tip.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants