Feels Like Forever :: FFR Batch Submission
kadef -
Feels Like Forever -
kadef [5 / 10]
Feb/March 2021
PublicEvents
Rejected
Simfile Folder Name
Feels Like Forever (kadef)
Note Count
1357
Chart Length
3:23
Average NPS
6.8374
Estimated Difficulty
61.68
First Note
0:04
Ending Note Delay
0:05
Hand Bias
Framers
0 - 0
1 - 0
2 - 0
3 - 12
4 - 9
Jumps
Hands
Quads
Color Jumps
Color Hands
Color Quads
Most notes in:
1/3 of a Second
7 - 21.00 nps
0.5 Seconds
9 - 18.00 nps
1 Second
16 - 16.00 nps
2 Seconds
28 - 14.00 nps
5 Seconds
65 - 13.00 nps
10 Seconds
115 - 11.50 nps
30 Seconds
304 - 10.13 nps
1 Minute
544 - 9.07 nps
Color Count
Largest Note Gaps
4.37s4.13s3.07s1.87s1.77s1.57s1.57s1.57s
Posted at 4:58pm on September 2nd, 2021
Have an issue with the syncing here. It's not an issue of wrong bpm in itself, but rather with it being a piano piece with a slightly fluctuating timing causing a lot of notes to be just off the waveform enough to be notice able. Not listing every one of these since they're constant throughout but just take a look at say the 8th at 2.479 or the section from 41.591 - 42.257. The 8th at 41.813, and 4ths at 42.035 & 42.257 are off a bit from the waveform spikes. Noticing you've got subbeats spread out in your file and stuff like this is why the subbeats are important but you're not using them in spots like the area I pointed out where it's off.
-6.489: Noticeable grace that could be stepped here
-11.165: Wouldn't use (4) in this jump here to better match PR with the 4th before it at 10.479
-12.680: Noticeable grace
First jumpstream section plays well minus several spots that force one-hand minitrill where it doesn't seem to match PR:
+29.035: Change (3) to a (2) to avoid 3434 trill
+45.257: 21212 trill
+47.368: (2) and (3) changed to (1) and (2) to better match PR in ascending line and to avoid 343434 trill
+48.479: Would adjust either the (1) usage in this jump or the (1) at 48.924 to avoid the three repeated (1)s there
+51.368: 3434343 trill
+53.146: Same as 48.479
+54.035: 1212121 trill
+55.479: Same as 29.035
+58.591: 121212 trill
113.813 - 125.924: Suppose these hands are okay but considering the intensity the rest of the hands in the file are going to, I believe jumps fit better here
200.257: Don't think the volume or length of this last held-out ending note warrant a ghost note like this that's so far out. Either remove it or bring it closer to the actual note.
*Overall really nice song and smooth-ish jumpstream aside from the mentioned one-hand trills that clash with PR, but the main issue here has to be the sync not quite matching the fluctuating piano throughout the file. With it being the whole file and not just one or a few tiny spots, I can't accept it as is as sync is really important when it comes to rhythm games. With those adjusted though, I'd see no reason not to have this in game.
Posted at 1:46pm on October 24th, 2021
An appeal was requested and the file was looked over by TC_Halogen, here are his notes:
Have an issue with the syncing here. It's not an issue of wrong bpm in itself, but rather with it being a piano piece with a slightly fluctuating timing causing a lot of notes to be just off the waveform enough to be notice able. Not listing every one of these since they're constant throughout but just take a look at say the 8th at 2.479 or the section from 41.591 - 42.257. The 8th at 41.813, and 4ths at 42.035 & 42.257 are off a bit from the waveform spikes. Noticing you've got subbeats spread out in your file and stuff like this is why the subbeats are important but you're not using them in spots like the area I pointed out where it's off.
-6.489: Noticeable grace that could be stepped here
-11.165: Wouldn't use (4) in this jump here to better match PR with the 4th before it at 10.479
-12.680: Noticeable grace
None of these I find to be particularly egregious; I can agree with the note on 11.165 for the purpose of pitch relevance, but the omission of grace notes is fine given that in general, they’re not really given much credence at all throughout the song. It seems very much like a deliberate omission.
First jumpstream section plays well minus several spots that force one-hand minitrill where it doesn't seem to match PR:
+29.035: Change (3) to a (2) to avoid 3434 trill
The PR is actually fine as it is; those four notes are back and forth in terms of pitch and given that it’s a constant stream, it serves as an acceptable accent. The song isn’t particularly fast either, so it’s not like this is a jarring increase in difficulty.
+45.257: 21212 trill
I do agree that this pattern could probably be reworked slightly -- you also have good reason to do this to give a different jump between 45.368 and 46.257 for slightly better PR.
+47.368: (2) and (3) changed to (1) and (2) to better match PR in ascending line and to avoid 343434 trill
Starting with L/D actually breaks PR on the 16ths, but I do agree that the one-hand trill could be avoided -- I’d use something like L/D/R/D/(jump), then L/D/R/U/(jump), since the notes at 48.146 and 48.368 are in fact different.
+48.479: Would adjust either the (1) usage in this jump or the (1) at 48.924 to avoid the three repeated (1)s there
I can level with this; don’t think it’s required but I can see this as a fair suggestion as well. Starting with D/U into L/D will give a slightly better ascending feel.
+51.368: 3434343 trill
Definitely agree with this; this is probably the most egregious pattern so far given that it also involves hitting a triple. The jumps before this triple are technically out of order in terms of pitch relevancy (switch the
and [LD]) -- between that switch and the 3-note 16th melodic patterning, some different patterns can be done to mitigate that a bit.
+53.146: Same as 48.479
+54.035: 1212121 trill
Brief change of PR on the jumps should be able to alleviate this trill from being necessary; I agree with the change as well.
+55.479: Same as 29.035
This is actually a different interval than the first instance, it seems; the note at 55.257 could be changed.
+58.591: 121212 trill
Can also agree, this trill can probably be reduced with slightly different descending PR on the jumps.
113.813 - 125.924: Suppose these hands are okay but considering the intensity the rest of the hands in the file are going to, I believe jumps fit better here
I think the triples are an effective accent here because jumps are being leveraged as a layering mechanism, and then a layer of notes literally gets added on top of it. Nothing in here is intrusive to reduce playability, it feels okay.
200.257: Don't think the volume or length of this last held-out ending note warrant a ghost note like this that's so far out. Either remove it or bring it closer to the actual note.
I’m not going to really comment on this either way; given that FFR does not truly have a concept of sustains, I think that this note existing this far out is *fine* -- though I would move it slightly back to actually land where the note sustain concludes; in current point, I think it’s just a touch after the sound disappears.
*Overall really nice song and smooth-ish jumpstream aside from the mentioned one-hand trills that clash with PR, but the main issue here has to be the sync not quite matching the fluctuating piano throughout the file. With it being the whole file and not just one or a few tiny spots, I can't accept it as is as sync is really important when it comes to rhythm games. With those adjusted though, I'd see no reason not to have this in game.
I actually agree with a majority of the notes for this song; the changes suggested are generally reasonable and I don’t think there’s anything forcing the chart to be something that it shouldn’t. However, I feel like the damage given to the rating for something of this quality is a bit on the strong side -- when playing this at 100% speed, it’s pretty clear what the intent is. While there are some moments where realism of the fluctuations are not captured in more abrupt gap changes, I don’t think there’s anything particularly huge. It’s structurally sound, and clear in intent. I’m going to recommend this being moved from rejected to conditional queue status -- I do think there are enough sync issues to where the file should have some cleaning up done, but I don’t think it should be forced as a brand new submission in a batch.