pip uninstall ffmpegio
pip install ffmpegio-core

Is there another way im meant to do this? cause doing these just produces the
"ModuleNotFoundError: No module named 'ffmpegio'"

That's strange... If you pip list do they appear?

BTW, here's an GitHub repo just created for the code above.

Pip list gives (after uninstalling ffmpegio):

Pip list gives (after re-installing ffmpegio):

I ran the code on each of them, both gave the same index error listed above. (The index error)

I would assume that this is probably something on my end, but I tested in different directories, different files, and it seems to give the same error

Oh, you don't need ffmpegio package. ffmpegio-core package is all you need. ffmpegio package is actually installing ffmpegio-plugin-numpy plugin module. Yeah, it's confusing but it's done this way for a historical reason. At v0.3.0, I split ffmpegio-core from ffmpegio to remove the numpy dependency.

Solved by creating a new venv. Dont know why it was mad at me though

Yeah fading in and out is a common operation of most audio projects. Chaining them together is a totally different story though.
In Pydub, you could easily stitch two AudioSegments together and use a .crossfade() or whatever one them, but if you wanted it to happen to many audiosegments, seamlessly, it is a lot harder.

Because you couldn't just continually append them together without some type of 'cut' between them when you switch to a different AudioSegment (crossfading would combine two together).

A helpful part of the no 'time.sleep()' stuff by default, is that this operation becomes slightly easier. Instead of messing around with those audiosegments and trying to line them up, you took a totally different approach. (Note: It was theoretically possible to do this using 'silence' and having two tracks playing at the same time, and while one track is playing music, the other is playing silence, and when the song is ending, the one that was playing silence begins to play it's song. I made an illus
tration on how it works)

With no time.sleep(), it, (again, in theory) seems a lot easier to implement crossfade. Can't say for sure without spending a few dozen hours perfecting it though

Different operations, such as pausing, scrubbing (or parsing) though the song, resuming, all seem a little bit more difficult with this implementation, making sure that with each pause / play (especially on longer tracks, where more pauses could = some type of desync) lines up successfully, without being off at all.

This would also totally be more resource intensive than no crossfade. I'm unsure if pydub's silence occupies the same amount of memory as regular AudioSegments, but if so, a 15 minute video could easily break 300mb of memory, which IMO, is waaay too much

I think what you're facing is the limitation of simpleaudio. It is called simple for a reason. :-D

Have you considered pyaudio? pyaudio's stream class will give you much more flexibility and will massively reduce the memory footprint.

No, you have a list, the list contains objects. The objects represent a song. Each object has the following attributes:

Title
Author
Album
SavelocationThumb
Savelocation
Unique id

The list is derived from sqlite3 tables, which are basically playlists. So a user can create playlists, which is essentially a 1:1 recreation of the table, if that makes sense.

Unique id is the primary key for the database
Savelocations are the locations on the user's device where the song / thumbnail is saved

The music class is used to move around this list. For shuffle, it random.shuffle(my_list), then has a reassemble function to put it back together. You can also specifically play the song of your choice, skip forwards & backwards. Basically all of the features you'd expect from a music app besides the ability to scrub through a song.

If you look briefly at the class attributes for 'music_player' (line 447), you can see all of the attributes, and what they do.
It is used by creating one instance of the music player class on app startup, then changing it while using the app

OK, I'm getting a better sense of how crossfade is being implemented in pydub (and I see how inefficient pydub is).

Am I correct that it is not doing true seemless crossfading? There must be a split second between 2 songs.

I think you can do true crossfading with ffmpegio+pyaudio although you must implement the crossfading mechanism yourself:

1. add fade-in and fade-out filters to ffmpegio reader
2. add previous fade-out samples + next fade-in samples before queuing the overlapped samples to the pyaudio player

If this makes sense to you...

To be fair to pydub, it wasn't exactly meant to be used for playing audio in this sense. It has a lot of functionality for analyzing and processing audio, rather than more 'personal' playing music.

It does have true seamless crossfade, but only for a select amount of audio segments. Basically: Song1 + Song2 = (Song1 [crossfade here] Song2). <- Being one audiosegment.
Again, the problem is chaining a bunch of them together for full seamlessness. You'd need to turn that 2 audiosegment -> 10, or 100 song audiosegment for true seamlessness.

I think having more control over the crossfade, like you mention, directly editing the samples and whatnot will probably provide a much nicer experience than using and interface, which uses and interface that uses ffmpeg.

Again, a bit over my head, but im sure when using it, it'll come easy

On 'testfile_generator.py', what exactly is it yielding when returning?
yield [generate(i) for i in range(nfiles)]

Paths to temporally audio files it generates. Once your main execution goes out of with scope, all these temp files get deleted. Do print (files) in the main script to see what it looks like.

And I guess this ties into that, but right after the context manager in 'pyaudio_player.py':

with testfiles(1) as files:
   file = files[0]

Why does we only use the [0] of the testfiles(1)? What is it's purpose?

As the generator function name testfiles suggests, it always returns a list of filepaths. On the plain pyaudio player script, it can only play 1 audio file, so it's generating 1 file (the first argument=nfiles) and only using the first and only entry.

Also the sleep(0.1):

# wait for stream to finish
while stream.is_active():
   sleep(0.1)

What is the purpose of that? I removed the time.sleep and it acted fine. I'm assuming with this information, this has nothing to do with the time.sleep() stuff i was talking about with how my program works?

It's the same. Without sleep your main thread stays busy constantly checking the state of the player, needlessly burning PC resources. Ideally, you'd want to use thread.join() or process.wait() to wait for another thread/process, but pyaudio does not expose any method like that. I may deep-dive portaudio source in the future to see if a feature like that can be added.

Meanwhile, keep your sleep() lines intact.

Yeah I see what you mean with the testfiles. I figured out how to play my own song fairly easily. Just setting the ffmpegio.open()'s first value to the path to my song.

Also, is there any native way to get the time passed in the song? That was one of the problems I had. I actually had a very similar implementation, that didn't get added to my app because I sort of feared that constantly updating the time left / time passed in a song would generate significant overhead. Yes, you could use flags or whatever, but I hadn't gotten that far.

Also, have you gotten to test the memory usage for playing the files? I would love the flexibility of not struggling to play long (40m+) videos without wondering if it has a memory leak or something.

I also had the problem, that I sort of had to band-aid fix; where long videos would take a fair bit of time to initialize, and if someone clicked play (begins to init long video), they could click again, and cause some playback errors. I had to fix it by putting a cooldown on the button. I'm sure if we get this project up and running, it should likely solve that issue.

Also, is there any native way to get the time passed in the song?

This is the major shortcoming of both simpleaudio and pyaudio. They offer so little to monitor the state of audio playback. As I mentioned below, Qt's QAudioSink opens up a possibility to track the seconds played elapsedUSecs(). You may want to look into the world of PyQt6/5

Also, have you gotten to test the memory usage for playing the files?

No. But it shouldn't drive up memory usage at all as the buffer size is fixed throughout.

Have you had chance to study the crossfade example?

I have not had a chance to thoroughly look at the crossfade example. I was mostly poking around with the more basic example is 'pyaudio_player.py', as to understand a bit more of this 'low level' audio manipulation. I'm really trying to build the solid foundation of understanding the regular player, in and out, before moving on to the crossfade.

In the context of my project, crossfade will not be implemented for a little while. It is just so dang hard to implement. Perhaps, at it's minimum, crossfade is not difficult, as you showed me in the example. However, incorporating traditional media player functions into that mix is a different story. For example, skipping a song. Skipping a song with the regular class I'm using right now in Punge works well. You increase the song_count by 1 and move on. Throwing crossfade into that might be a new can of worms in terms of bugs. Where do you skip to exactly? Before the crossfade has fully finished or the end of it? Do you start a whole new 'instance' all together where there is no crossfade in the beginning?

Would I like to have crossfade? Of course. Is it (going to be) difficult? Probably.

I have not had a chance to thoroughly look at the crossfade example. I was mostly poking around with the more basic example is 'pyaudio_player.py', as to understand a bit more of this 'low level' audio manipulation. I'm really trying to build the solid foundation of understanding the regular player, in and out, before moving on to the crossfade.

That's a sound idea. The complexity of the crossfade example is much much higher in terms of how you pass around a buffer of sound samples from thread to thread. Once you understand how pyaudio's callback works, you're 90% of the way there IMO.

Throwing crossfade into that might be a new can of worms in terms of bugs. Where do you skip to exactly? Before the crossfade has fully finished or the end of it? Do you start a whole new 'instance' all together where there is no crossfade in the beginning?

Crossfade and skipping are 2 completely different animals at least in how my demo is written... actually to skip a song, you do need to stop and restart (pyaudio doesn't let you clear the buffer during playback). Meanwhile, crossfade is automatically inserted between tracks.

Would I like to have crossfade? Of course. Is it (going to be) difficult? Probably.

With pydub without a question, it would be hard. Once you get used to buffered "realtime" playback, you may find it much easier.

Actually, I currently don't have any interest in creating a player. I'm using this opportunity to learn how to interface FFmpeg with various audio player packages. My hope was that you can go back to your Punge and incorporate ffmpegio to it. I'd be happy to help.

Oh, another thing... If you ever want to learn new UI framework, look into Qt. It has control interaface for audio device. I'll give it a try next.

I actually did have plans to use Qt5 to re-do my GUI, I've just been super lazy in doing so. I'm assuming the docs you linked also has a python equivalent because those are for c++ lol.

My limited experience with PyQt, I found C++ documentation is all you need as everything is essentially there as is in Python (ofc only if you are proficient in C++). (Tricky ones being find the constants.) No idea if there is PyQt counter part to QMultimedia documentation.