More of a general thing:
You have 2 big sprites you keep reusing for flashes and strobing, namely in line 28 and line 146520.

From a design standpoint it is in fact better to create a new sprite whenever you have a reasonable long time of invisibility between sprite uses.
This storyboard does not have performance problems due to using the GOOD spectrum so you don't need to fix it if you don't want to but splitting those up into multiple sprites would be better performance wise.
osu! will keep running through all of the commands (even those it doesn't need to perform yet or those it already performed!) for the entirety of its active time (first starttime till last endtime) which means it will run through many commands that aren't really relevant at that point. If this happens with effects that use more sprites (especially particles), this can quickly lead to performance issues.

Feel free to resolve without changes.

3.3MB is an absolute insane filesize for a 1920x1080 background and so are 2MB for the blurred version.
The blurred version being MUCH smaller should already indicate that you can probably get a much smaller filesize without significant quality loss.
Experiment a bit with export settings and you should be able to get both of these below 1.5MB with no visible difference.

The metadata effect is getting initialised too early, e.g. in line 146492:

Sprite,Background,Centre,"sb\Title.png",0,0
_S,0,0,,0.5
_MX,0,0,,535
_MY,0,0,,250
_F,0,4622,4792,0,1
_F,0,4792,7179,1
_F,0,7179,7349,1,0

should instead be

Sprite,Background,Centre,"sb\Title.png",535,250
_S,0,4622,,0.5
_F,0,4622,4792,0,1
_F,0,4792,7179,1
_F,0,7179,7349,1,0

Moving the position to the sprite initialisation is not super necessary but likely very easy to do for something like this which is probably coded with hardcoded values.

The teleporting blue dot effect at 02:34:409 - is getting initialised at the start of the SB but only used way after, see line 146464:

Sprite,Background,Centre,"sb\dot.png",0,0
_L,153428,2
__MX,0,0,,415
__MY,0,0,,240
__MX,0,170,,655
__MX,0,341,,525
__MY,0,341,,120
__MY,0,511,,360
__MX,0,682,,415
__MY,0,682,,240
_F,0,0,,0 <--- get rid of this one
_F,0,153428,,1
_S,0,153428,,2
_F,0,154621,,0

Same for other uses of the same effect.

osb file is in the folder twice -> remove the one with the old metadata in the filename

Nice slideshow SB, good luck!

You flipped EndTime and StartValue for your Fade commands in line 4, 264 and 277 respectively:

Sprite,Background,Centre,"kalibe.jpg",0,0
F,0,202438,0,202938,0.75 <---
S,1,202438,203288,1.090741,0.6666667
M,0,202438,268754,320,220,320,240
F,0,268754,,0.75,0

Sprite,Background,Centre,"sb\bg\6.jpg",0,240
F,0,161385,0,161885,0.75 <---
S,1,161385,162235,1.2,0.6
MX,0,161385,189806,260,300
F,0,189806,192806,0.75,0

Sprite,Background,Centre,"homura.jpg",0,240
F,0,66648,0,67148,0.75 <---
S,1,66648,67498,1.2,0.6
MX,0,66648,95069,260,300
F,0,95069,,0.75,0

osu! seems to be able to cope with it somehow but these commands arguably make no sense as they are now.

The fire spark particle effect is kind of nice...however if you want it to be more realistic I would suggest you make the sparks go up instead of down.
If you check any real life fire or videos of such, you'll find that sparks rise up into the air until they lost too much heat so that would probably look a bit more natural.

The transition effect you use at 01:34:675 - creates way too many sprites.

It starts quite a bit too far to the left as seen in line 312:

Sprite,Foreground,Centre,"sb\p.png",-420,240
R,0,94280,,0.1
C,0,94280,,0,0,0
V,0,94280,94580,0,500,30,500
F,0,95069,,1,0

and then goes way far on the right as seen in line 807:

Sprite,Foreground,Centre,"sb\p.png",2550,240
R,0,94280,,0.1
C,0,94280,,0,0,0
F,0,95069,,1,0
V,0,95171,95471,0,500,30,500

Considering you're using 30 pixel differences between your sprites and you have a slight tilt, it will suffice if you spawn these sprites from -150 to 780, everything else is just useless off-screen load.

Your other uses of the effect seem to have same problem with varying degrees overshooting so recheck them too.

For the squares that are moving up in the background you could save a LOT of commands.

As an example, in line 30723 of your .osb you have one such sprite looking like this:
Sprite,Foreground,Centre,"sb\pink.png",0,0
R,16,90581,90718,0,1.570796
F,0,90627,,0.45
S,0,90627,,0.12
M,22,90627,90809,120,490,120,442
R,16,90763,90899,0,1.570796
M,22,90808,90990,120,442,120,394
R,16,90945,91081,0,1.570796
M,22,90990,91172,120,394.0001,120,346.0001
R,16,91127,91263,0,1.570796
M,22,91172,91354,120,346.0001,120,298.0001
R,16,91308,91445,0,1.570796
M,22,91354,91536,120,298.0001,120,250.0001
R,16,91490,91627,0,1.570796
M,22,91536,91718,120,250.0001,120,202.0001
R,16,91672,91809,0,1.570796
M,22,91718,91900,120,202.0001,120,154.0001
R,16,91854,91990,0,1.570796
M,22,91899,92081,120,154.0002,120,106.0002
R,16,92036,92172,0,1.570796
M,22,92081,92263,120,106.0002,120,58.00019
R,16,92218,92354,0,1.570796
M,22,92263,92445,120,58.00022,120,10.00022
R,16,92399,92536,0,1.570796
M,22,92445,92627,120,10.00024,120,-37.99976
R,16,92581,92718,0,1.570796
M,22,92627,92809,120,-37.99974,120,-85.99973

Kind of obvious here is that you're essentially just repeatedly rotating the sprite on a set interval from 0 to pi/2 which would save a lot of commands (and filesize) given that there are hundreds of these. So just from looking at the rotation this can instead look like this:

Sprite,Foreground,Centre,"sb\pink.png",0,0
_L,90536,12
__R,16,45,182,0,1.570796
_F,0,90627,,0.45
_S,0,90627,,0.12
_M,22,90627,90809,120,490,120,442
_M,22,90808,90990,120,442,120,394
_M,22,90990,91172,120,394.0001,120,346.0001
_M,22,91172,91354,120,346.0001,120,298.0001
_M,22,91354,91536,120,298.0001,120,250.0001
_M,22,91536,91718,120,250.0001,120,202.0001
_M,22,91718,91900,120,202.0001,120,154.0001
_M,22,91899,92081,120,154.0002,120,106.0002
_M,22,92081,92263,120,106.0002,120,58.00019
_M,22,92263,92445,120,58.00022,120,10.00022
_M,22,92445,92627,120,10.00024,120,-37.99976
_M,22,92627,92809,120,-37.99974,120,-85.99973

This way you're essentially going to save almost half the commands per sprite which in turn almost halves the command mountain above.
(There's a 45ms delay between rotations so I added that to the rotation inside the loop to keep it and substracted it from the initial start time)

As you can see the sprite in line 30723 only changes in the Y part, so you could reduce the fliesize taken up by these sprites by only using MY commands instead, like this:

Sprite,Foreground,Centre,"sb\pink.png",120,0
_L,90536,12
__R,16,45,182,0,1.570796
_F,0,90627,,0.45
_S,0,90627,,0.12
_MY,22,90627,90809,490,442
_MY,22,90808,90990,442,394
_MY,22,90990,91172,394.0001,346.0001
_MY,22,91172,91354,346.0001,298.0001
_MY,22,91354,91536,298.0001,250.0001
_MY,22,91536,91718,250.0001,202.0001
_MY,22,91718,91900,202.0001,154.0001
_MY,22,91899,92081,154.0002,106.0002
_MY,22,92081,92263,106.0002,58.00019
_MY,22,92263,92445,58.00022,10.00022
_MY,22,92445,92627,10.00024,-37.99976
_MY,22,92627,92809,-37.99974,-85.99973

The entire thing becomes even more effective if you reduce the accuracy of the coordinates because none will be able to spot any changes to more than 1 pixel accuracy for this kind of effect anyway.

Sprite,Foreground,Centre,"sb\pink.png",120,0
_L,90536,12
__R,16,45,182,0,1.570796
_F,0,90627,,0.45
_S,0,90627,,0.12
_MY,22,90627,90809,490,442
_MY,22,90808,90990,442,394
_MY,22,90990,91172,394,346
_MY,22,91172,91354,346,298
_MY,22,91354,91536,298,250
_MY,22,91536,91718,250,202
_MY,22,91718,91900,202,154
_MY,22,91899,92081,154,106
_MY,22,92081,92263,106,58
_MY,22,92263,92445,58,10
_MY,22,92445,92627,10,-38
_MY,22,92627,92809,-38,-86

This finally takes up less than half the filesize. Given that this effect in total takes up about 1/3 of your entire .osb, this would save roundabout 400kb in filesize. So not bad but also not terribly necessary, consider if it's worth the effort and feel free to close without changes if it's not.

The same principle for using loops applies for all of your center sprites (the circle parts rotating around the square) which are starting in line 40131 / 01:10:241 -

Sprite,Foreground,Centre,"sb\r1b.png",320,240
_F,0,69354,69445,0,1
_S,19,69354,69581,0,0.52
_R,0,69536,90263,0,43.9823
_S,0,69581,69718,0.52,0.36
_S,19,81535,81626,0.36,0.414
_S,0,81626,81808,0.414,0.36
_S,19,82262,82353,0.36,0.414
_S,0,82353,82535,0.414,0.36
_S,19,82990,83081,0.36,0.414
_S,0,83081,83263,0.414,0.36
_S,19,83717,83808,0.36,0.414
_S,0,83808,83990,0.414,0.36
_S,19,84444,84535,0.36,0.414
_S,0,84535,84717,0.414,0.36
_S,19,85172,85263,0.36,0.414
_S,0,85263,85445,0.414,0.36
_S,19,85899,85990,0.36,0.414
_S,0,85990,86172,0.414,0.36
_S,19,86626,86717,0.36,0.414
_S,0,86717,86899,0.414,0.36
_S,19,87353,87444,0.36,0.414
_S,0,87444,87626,0.414,0.36
_S,19,88081,88172,0.36,0.414
_S,0,88172,88354,0.414,0.36
_S,19,88808,88899,0.36,0.414
_S,0,88899,89081,0.414,0.36
_S,19,89535,89626,0.36,0.414
_S,0,89626,89808,0.414,0.36
_S,19,90262,90353,0.36,0.414
_R,0,90263,93354,43.9823,69.11504
_S,0,90353,90535,0.414,0.36
_S,19,90990,91081,0.36,0.414
_S,0,91081,91263,0.414,0.36
_S,19,91717,91808,0.36,0.414
_S,0,91808,91990,0.414,0.36
_S,19,92444,92535,0.36,0.414
_S,0,92535,92717,0.414,0.36
_F,0,93354,93355,1,0

All the repeating scale changes can go into a loop instead:
Sprite,Foreground,Centre,"sb\r1b.png",320,240
_F,0,69354,69445,0,1
_S,19,69354,69581,0,0.52
_R,0,69536,90263,0,43.9823
_S,0,69581,69718,0.52,0.36
_L,81081,16
__S,19,454,545,0.36,0.414
__S,0,545,727,0.414,0.36
_R,0,90263,93354,43.9823,69.11504
_F,0,93354,93355,1,0

Not suuuper big but if you do it across all the sprites for the center effect this should add up to several hundred commands being saved and since this reduces the current peak load, this is something you should consider doing.

In some parts, the spectrum just looks choppy. If you check out some parts like 01:47:698 - you will find that in some moments there are super big movements in almost no time which looks rather bad. Not sure, maybe you want to look into that, feel free to resolve if not.

Another thing I would suggest for the spectrum is maybe removing the rightmost bar because it is not moving at all. Alternatively you can try to change the line
var fft = var fft = GetFft(time + fftOffset, BarCount, null, FftEasing);
to just
var fft = GetFft(time + fftOffset);
The former cuts off a lot of the spectrum on the right part through the InExpo-Easing that you're probably using. This can be good because the high frequency stuff is not very audible and con look a bit random but if stuff is not moving at all I think that's still preferable.

Additionally the loop thing applies once again in the Kiai for the mild flash effects you use with bgBlurBright and the likes (line 145). Using a new sprite for each "flash" as seen starting from line 288 is also kind of acceptable instead of a loop but only preferable if there are a bit bigger gaps between each fade in.

The bg is removed twice, once in line 5 and once in line 140, once should be enough. Additionally right at the start of your .osb there are 2 sprites that just get faded to 0 and never become visible.

In line 15231 there is a sb\white.png that is prematurely initialised with a F,0,0,,0 even though it won't get used for another 2min, remove that single fade command.
Same thing occurs in line 42581

Your mania columns at 00:55:229 - have for some reason a couple duplicate commands you can remove. https://endaris.s-ul.eu/TRXlBhCX.png
e.g. in line 64496 and 64497, there's the same command twice.