Sometimes a song will have some audio of the last song in the beginning

[torkeldanielsson]

Most songs will have extra leading silence. Some songs will have a bit of audio from the last track in them.

I made this script and after running it I'm happy with how the songs begin. Some songs might be trunkated! But I prefer this over the silence/junk:

for i in */*.mp3
do
    ffmpeg -ss 0:01 -i "$i" -acodec copy "$i.out.mp3"
    rm "$i"
    mv "$i.out.mp3" "$i"
done

Is there some "feature" that I have accidentally turned on that causes this?

(I looked through old issues and couldn't find this mentioned, sorry in advance if I missed it.)

---

IssueHunt Summary

Backers (Total: $25.00)

• bziorkiewicz ($25.00)

Become a backer now!

Or submit a pull request to get the deposits!

Tips

• Checkout the Issuehunt explorer to discover more funded issues.
• Need some help from other developers? Add your repositories on IssueHunt to raise funds.

[kekkc]

Not sure if this is related, but with Spotify Free some songs contain 1s of the previous advertisment at the beginning.

However, if there was no advertisment before, they start on point for me.

[guillaumealgis]

Looking at the audio waves in audacity, it looks like the bit of the last song ending up in the next song is always lasting exactly 1s. I'm not sure where I could start looking to fix the bug (I'm not much of a C# guy), but could some delay somewhere in the code could be causing this?

[guillaumealgis]

So, after digging a bit in the code, my theory is that when the OnTrackChanged event is triggered (by Spotify updating its window title if I understand things correctly), WasapiLoopbackCapture will not necessary have finished triggering all its DataAvailable events for the current track (those events are processed asynchronously). So EspionSpotify will start a new Recorder for the next track while some data of the current track is left to be written, and it gets written to the new Recorder (and so the next track file), hence this bug.

The "1s" number I referred to in my previous comment seems irrelevant, it'll depend on the conditions the program is running in (i.e. how long the CPU takes to finish writing bytes read from WasapiLoopbackCapture to disk).

My workaround for now is to add a delay of about ~800ms (again, determined for my machine) before triggering the OnTrackChanged event. It's finicky at best and I'd love a better solution, but it'll work for my needs short term.

I guess one way to solve this properly could be to detect a silence in the WasapiLoopbackCapture stream after we received a OnTrackChanged event, to know where to cut the tracks (assuming there's always silence between two tracks, which I'm not convinced of).

[issuehunt-oss]

@bziorkiewicz has funded $25.00 to this issue.

---

• Submit pull request via IssueHunt to receive this reward.
• Want to contribute? Chip in to this issue via IssueHunt.
• Checkout the IssueHunt Issue Explorer to see more funded issues.
• Need help from developers? Add your repository on IssueHunt to raise funds.

[bogzio]

A short-term workaround could be an option in the settings to delay next recording by X ms. I tried to just edit these mp3 files - cut from the next one and paste into the previous but there seems to be a very short gap between recordings, so even after merge there is a very short silence in the place of merging.

[maliayas]

It looks like there is no easy way to fix this automatically.

I'll propose another approach. This bug happens when there is no silence at the end of a song. After such a song, the next played song has an unwanted sound prefix. So, such songs without a silence suffix at the end must be handled manually. If only SpyTify could detect such songs and skip recording the next song after it (because it would have a buggy prefix) and print this in the logs, user then would manually replay those unrecorded songs and record them; this time working because problematic songs (without silence suffix) are not in the playlist any more.

[maliayas]

I noticed that @bziorkiewicz has suggested a good idea in another issue (closed): controlling playing from directly SpyTify which would allow waiting a few seconds between each song.

[matteorizzo]

I'm not very familiar with GitHub, but I see this marked as "Done" and progress of the next release as 80%.

This is a really needed feature. Is there any funding that would speed that up?

[JSorcerer]

As @guillaumealgis told on previous comments, the MainWindowTitle of Spotify process changes the title of the track that is played to the next song one second before the actual track is ended, this happends on all tracks, but it's noticed only on tracks that not finish with a silence, like @maliayas pointed. I think the proposal of @guillaumealgis is great, is a good approach because personally I don't mind if a song contains 1s of silence at the end of the song, as long as the song not contains audio from the previous track at the start, or ends up with a cut in the song.

[jwallet]

This is stil a work in progress, I even created a fake spotify inside the project to test the AudioThrottler that it's still not working properly. I cannot work on it as often as I want, since I'm on a Mac now. and don't have access at all time to a windows pc. Even if this throttler does work, I don't know how it will be able to split two tracks that have no silence in between. Adding just a delay was not enough, Spotify changes its title randomly, so sometimes the delay needed was -200ms, sometimes it was 400ms or 800ms, and some other times no delay. This is kind of tricky.

[shardrunner]

At least previously (think v1.11.1) it would sometimes also not correctly split for me, if there was a silence between the songs.
Then it would record some very short audio of the end of the previous song, a short silence and then the actual song on the recorded track.
The previous track ended a bit too early in the recordings then.
Maybe I can try it again with 1.12 in the next days, if this is still the case.

[paulbogo]

Hello, my solution to this problem was to edit into project EspionSpotify.sln:
System.Threading.Thread.Sleep(1050);
the only problem is that when we record, we have to play the first track, and then stop and then play again to dont cut the start of the first song. after that, it remains to cut the first piece from the first track. I use the function auto-trim-crop from SOUND FORGE to cut the silence from start and end of the rest of the songs

[exitflynn]

i looked around on this issue, and wanted to clarify if everyone here didn't have the crossfade feature on. If not, then there's a chance that perhaps the bug was coming up due to the playlist being one of those playlists from Spotify which have crossfade on by default. Here's more information on that.
Hopefully this helps solve this issue.

[shardrunner]

I think that's not the problem for me, as it's a custom playlist and crossfade is off.
There is also a silence between the songs, it just sometimes, but not always, happens to be on track 2 with "end track 1, silence, track 2" being saved as track 2.

[tomoprime]

I don't know if progress was made in this issue but what I do manually is restart the track as a one-off record. Seamless playback while ongoing recording introduces some artifacts. For songs that begin with the tail end of previous song or an ad clip I would get much better gap transitions between songs by doing this:

1. Start client track play for 30s. Spying is off. Potential of letting an ad play.
2. pause client playback, and rewind the track
3. click start spying
4. unpause client playback to record
5. click stop once on spying to end continued recording (one off record)

Repeat this process for any of the affected songs. It's a bit tedious but this is one way to replace tracks. Does the S-API allow for some client control in tandem with Spytify running in the background? Perhaps even sending a hot key is a workaround.

[jwallet]

The AudioThrottler now works, it will be available in the next release

[paulbogo]

when do you think the new version will be released?

[jimmyeao]

is there a branch we can compile to try this out?

[XorOwl]

if jwallet is still around i'm even willing to put a few more beers on his desk for this resolution.

I can't tell if this project is abandoned, on hiatus or just really really stuck on a problem.

Speak up if you're out there my guy, hope you're well!

[Assault]

What helped for me, was disabeling those two points in the spotify settings:

[Andrearincoc]

Uploading copy_6E5D6BB6-9FBD-4784-B2E9-84DE3F7B4FAA.mov…