Skip to main content

Notice

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.
Topic: New foo_input_reverse by Peter - a request for changes (Read 3169 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

New foo_input_reverse by Peter - a request for changes

Some may have noticed, some not, that right now we have an official component that allows reversed playback of our music:
http://www.foobar2000.org/components/view/foo_input_reverse

However this not new idea - in the past other developer (as far as I remember banned from here) has also released foo_input_reverse. There are 2 main differences beytween those 2x foo_input_reverse :
- older one required additional library (libmmd.dll) to operate
- older worked immediately and straightforward. New one does not...

Dear @Peter - I would like to ask you for making some changes to this plugin:
- could it work without adding a new playlist? Creating new playlist might be good idea, if someone tried it on an Autoplaylist entry, but on standard playlist it's bit odd. Could this behavior be differentiated based on playlist type (std - no new playlist / autoplaylist - new playlist is created)?
- could it work immediately? I mean - even if new playlist is created, then I would expect foobar to simply jump playback to that playlist and start playing there. If I choose command like "Play reverse" from keyboard shortcut it means for me that I want it now - not when track finishes nor when playlist finishes, and especially not after additional special clicking (changing focus and firing playback on new playlist).

Re: New foo_input_reverse by Peter - a request for changes

Reply #1
How about doing reverse like I would have suggested some time ago? Instead of pre-processing the track completely, seeking backwards in 5-10 second increments and playing blocks of audio data, and trusting whatever it is to support speedy and consistent seeking.

 

Re: New foo_input_reverse by Peter - a request for changes

Reply #2
Because then emulated formats will suffer due to needing to decode up to that point.

I tested the current component and it works great on USFs. Though my CPU is a i7 4790.

Re: New foo_input_reverse by Peter - a request for changes

Reply #3
Hm, Is it possible to simply read headers, and then go to the very end of the file and read it from the back? And make the seekbar works backwards? Of course for all those emulated formats still full decode and caching would be necessary...

Re: New foo_input_reverse by Peter - a request for changes

Reply #4
What's in a name, but ... a name foo_input_bar suggests it provides a way to decode some format/codec <bar>.

Re: New foo_input_reverse by Peter - a request for changes

Reply #5
Hm, Is it possible to simply read headers, and then go to the very end of the file and read it from the back? And make the seekbar works backwards? Of course for all those emulated formats still full decode and caching would be necessary...

Thats not how input services in fb2k's ecosystem work. The reverse decoder is simply a proxy which decodes files with the input services registered, reverses the samples, and then plays that temp file back.

Theres no way to force input decoders to go backwards.