Please note that most of the software linked on this forum is likely to be safe to use. If you are unsure, feel free to ask in the relevant topics, or send a private message to an administrator or moderator. To help curb the problems of false positives, or in the event that you do find actual malware, you can contribute through the article linked here.
I made some small improvements, download from the same link. It will now reset the time if playback is stopped and it now asks for the playback time from the core and not the decoder, so it should no longer skip ahead.
Yep, after replacing the earlier one, it's near perfect for what I need! There exists the teeniest, tiniest buffer (it's so small I literally can't tell if it's forward or backwards) that I didn't catch the first few times using, only realising it when I tried focusing really hard on the transition and tweaking the fade in/out lengths for the manual track change. I have literally no qualms about it, it's practically invisible when listening casually, really don't bother trying to fix it.
An actual issue I noticed, however, is that (right as one of the songs ends) it tends to loop back only a bit, replaying the same part at the end over and over, then finally looping back to the beginning (Order: Repeat Track). I have no idea what's causing it, but after tweaking around a bit, I found that it seems to go back the exact same length of the Output Buffer (If I have a 2-minute song and a 10000ms Output Buffer, it goes back to 1:50~). It seems to be happening sporadically, sometimes not happening, sometimes happening once, sometimes happening more than once (in this case, the first repeat goes back about the same length as the output buffer, but then the next loopback is shorter? This behaviour is also sporadic, sometimes not occuring).
I didn't find this issue with the earlier iteration of the component, so perhaps it has something to do with the retrieving process (I have no clue XD). It's causing quite a big hamper in listening, so I've disabled it for now. Stupid me decided to replace the earlier DLL file with the new iteration, and it didn't save the previous version, so until it's fixed (or you allow downloading of the previous version yet again) I'll be out of it for now.
Again, thanks in advance! (And of course, thank you for dedicating your time to this XD)
Last post by Case -
I made some small improvements, download from the same link. It will now reset the time if playback is stopped and it now asks for the playback time from the core and not the decoder, so it should no longer skip ahead.
I got the component by just coding it for you. It keeps track of internal decoder time at the moment, which of course can be way ahead of what is heard if the output buffer is long. I can improve it now if this is what you're after.
Oh, I see! So is "highly experimental" just programmer slang for "I made it moments ago"? XD
Thank you so much!! You were under no obligation to, and yet you made one anyway!! I am sincerely grateful, perhaps neat pieces of software really do have neat people like you follow suit :)
Don't feel any pressure to, the DSP works great currently. If it's too much a hassle then I don't mind at all, it's already amazing enough that you did this in the first place!!
Compounding on what you said earlier about its reliance on the internal decoder, my current output buffer length was manually set to about 1030ms~ to accommodate for the fading event times I set earlier, but I saw it at about 2000ms later, not sure if I just set it that way without realising or if it's variable depending on what needs it.
If it's of no circumstance to you, then please, go ahead! The installed component already works many wonders, and the inherent offset isn't too much of an issue in casual listening, Can't thank you enough already XD
My (deepened) gratuity to you, fellow Foobar2000 expert!! :)
Last post by Case -
I got the component by just coding it for you. It keeps track of internal decoder time at the moment, which of course can be way ahead of what is heard if output buffer is long. I can improve it now if this is what you're after.
Last post by [JAZ] -
EncSpot might say "Gogo" because it sees a lame-kind header (in the Xing header if VBR) but not have the specific information that LAME has, so might asssume it was the Gogo version.
I kind of figured you were looking at a wrong component. You should try Preview.
Thanks but if that is playing first seconds of tracks, not exactly what I'm looking for. Anyway, found out I can easily add and remove the SKIP tag in multiple tracks with MP3Tag, so that problem solved
Enable by adding 'Retain Playtime' DSP to the active DSP chain. Abuses decoder shim tech that Peter added for my Skip Track component.
Again, many thanks!! Works great. :)
I've found that the transitioning from one track to another, whether intentional or not, adds about a 2-second forward offset to the next track's retained duration (so it's just a little off), and changing the fading duration in manual track changing doesn't necessarily mitigate it. I tried finding the source code for the component online to try my hand at fixing it (if even possible :'D) but to no avail. I'm not really sure where you got this experimental component from, but (aside from the 2-second offset) it works wonders! 1000% better than not having the functionality in the first place.
Then you add a chain, which is just a DSP preset, and add there the mix to mono. Whenever the device containing headphones in the name is used, it will use such DSP preset.
