ottozing, what is your average PLL execution time (without recog/AUF etc)? I need this to work out your PLL/OLL TPS and recognition time. Otherwise you appear to be right on the money with your solves, perhaps with a slightly slow OLL (but you have already mentioned that). Obviously Im familiar with OLLCP, but what is AntiDiag?
Thanks sososososo much for taking the time to develop this whole thing I'll time my PLL's later tonight. As for practice, I think I'll just practice F2L as it's the most time consuming part of a solve
I can just about manage sub 20 nowadays, maybe 20-21 seconds on others. On a bad day 21+
all of these are averages of 12, bear in mind for single stuff there is no recognition, particularly in LL, so it's probably a little faster than in an actual solve. Finally, I use two look OLL, knowing only a few easy cases for 1 look and full PLL:
cross: 2.38 - 11.9% of a solve (Pretty accurate
cross+1: 4.92 - 24.6%
F2L inc cross: 13.97 - 69.9% (This was a bad average of 12)
OLL: 3.39 - 17% (I had a 6 second single with a dot :/ the average was better but that time would have been well over 23 seconds)
PLL: 2.49 - 12.5%
this totals 19.85, so I'll round that to 20 or so considering it doesn't include OLL and PLL recognition, this is about my normal amount anyway.
The problem here is you haven't followed the instructions for what I need to do this properly, i.e. times including recognition, a baseline average from the same session, total last layer etc etc. Rounding to 20 sec and assuming a 0.15 sec total recognition is likely to be erroneous, thats 0.075 seconds per LL, no human being can recog and AUF in 0.075 seconds. Allocating no time for actual recognition, thats in excess of 13 TPS for the AUF. Allowing for recog time, you are achieving inhuman turn speeds. Or its a bad guess.
However, your cross is fine, your f2l is a bit slow. Aim for around the 12 second mark, around 160 bpm should do it. Work on lookahead, and make sure you are using efficient f2l algs, and are solving in all slots without excessive rotations. Execution wise 2.49 secs for PLL is fine (actually 0.5 sec ahead of the 20.5 curve), but you're OLL is at its limit. If you are doing 2 algs there in 3.39 seconds, then you should be able to do 1 alg in 1.6-1.7 seconds. Even if you were more like 2 seconds, youve still knocked a second and a half off your solve. The fact that this 3.39 includes no recognition is a concern. A 3.3 second execution only OLL is more like a time you would expect from a 32-33 second cuber. If this is 3.39 including recog, then you are about at your OLL limit. Either way, consider learning full OLL. If you can do 2 algs in 3.39 seconds, then you can do 1 alg in 2 or less.
Basically my recommendation is to work hard on your f2l, and consider learning full OLL. And if you want to post a proper set of splits I will happily review them.
Thank you, this was a most interesting set of solves. First impressions from the vid, the slower times seemed to correspond with a choppy f2l, the great times were when your lookahead was really working well. Maybe do some slow solves/metronome solves and try to get really consistent in your f2l, and your average will come down since there will be much fewer over 15 second times. Be on the lookout for particular cases you find very difficult to quickly spot or solve, make a note and then check out Mackys site of Absolute F2L and make sure you have a good alg, and practice the execution. Its amazing how finding half a dozen awkward yet common pairings and just systematically eliminating the problem improves overall solve speed.
Anyway, onto the maths, heres the spreadsheet:
It worked - Thank you Zeotor!
Cross - fair to good, no massive concerns here.
Cross + 1 - excellent, no pause finding first pair, executed at a fair speed.
F2L overall - fine, but my previous points still stand. If you can reduce inconsistency, then these times will plummet as your video shows occasional much better technique than the times indicate, let down by the odd awkward solve. This is all averaging out though to where you should be.
OLL/PLL recognition. Your recogs here are spot on. I mean really excellent. One would expect around 0.95 secs for recog and AUF, but you cruise through at 0.74 OLL and 0.58 PLL (this is based on the assumption of a similar TPS during PLL and OLL, if OLL is just executed slower, then it may appear from the numbers that its taking longer to recog). Since PLL recog is in theory easier than OLL, you may be able to squeeze a little more out of your OLL recog, I talked about ways to work on OLL recog in a previous post in this thread. Since this is an obvious strength of yours, it shouldnt take much to develop it further, but I think the OLL thing is perhaps more TPS (see later).
PLL execution. This is about at its limit. I think you should make it a goal to get them all under 2.5 seconds. Your average should be more like 2.2 seconds max, which I know its close to, but getting a PLL average down to around 2 seconds is very doable. All the usual suspects are dragging you down, F perm, E perm, N perm. Drill drill drill and watch some fingertrick vids (Breandan, Cornelius, Faz etc) and find a regrip minimised flowing execution, then drill drill drill some more. Since your T is so fast, have you considered the modified T perm version of the F perm? Are you using the Rowe E perm with the wierd ring finger trick or that rubbish old one with u2? Are you still using those badmephisto (R,U,L) N perms, when all the cool kids are doing z then (U,R,D)?
OLL : Here we have a little problem. Since OLL algs are around 2/3 of the length of PLL algs, we would expect them to be executed somewhat faster, however your PLL and OLL times are very similar, pointing to a weakness in OLL of either recog or execution. Watching the video, it appears that you have a lower TPS during OLL than your PLLs, so this may be an area to work on. Are there a few cases that you hate getting? Try timing all 57, maybe there are some that you find particularly difficult to flow through as smoothly as your PLLs. Try to ensure they are all under 2 seconds, and you want to average around 1.5 seconds. Also very doable. If you combine this with shaving a little of the recog as we discussed, then you are making easy improvements.
In summary: Work on consistency in your f2l identifying and eliminating awkward or long cases/slots and minimising rotations. Ensure lookahead is always working (few pauses slipped in from time to time smooth > choppy). Working on getting metronome solves up around the 210-220 mark may well help (your f2l is currently operating at the equivalent avg TPS of around 213 bpm.), but I'm betting you will hit a bit of a roadblock before then (maybe around 180-190) that will not come up on every solve. This is the plateau you must cross, so you can handle any situation at this speed without losing lookahead. When you can do 12 f2ls on the trot at this bpm without dropping a beat, then you have it. getting it right 3 out of 4 is not having it. Thats having it when the cases are easy.
Work on speeding up your OLL algs. Time each one and see if there are a few algs or a particular type of alg that is letting you down. Get them sorted. Read what I posted about OLL recognition and being very familiar with the orientation of all the stickers in the case, as opposed to just the ones you use for recognition. Achievable targets are all under 2 seconds, average of 1.5.
Your PLL is fine, but there are a couple of cases that could use a little work. Drill drill drill, and analyse your technique of execution to try and eliminate regrips. Compare it to other top cubers, and if necessary get new algs. Go for avg of 2 seconds, all under 2.5.
Your problem solves come when you have a couple of awkward f2l cases, a tricky OLL for you, then an awkward PLL. Case in point, you had one solve near 20 seconds! If the f2l cases are no longer awkward, the OLL has been drilled, and the PLL is not an issue, then your worst case solve is more like 15-16 seconds. What would your average of 12 be then? I could work it out exactly, but the basic answer is: faster.
One more thing I want to throw in for everybody reading this. Try this little exercise. Time and film 5-12 f2ls or full solves. Pick the worst one. Rip the soundtrack using any avi editor, and save it as an mp3 or wav file. Load the audio into a waveform editor like Audacity (totally free), and cut out all the waveform except the solve you are interested in. Now go along the waveform elimating any pieces of silence. Silence is when you are not turning the cube. Any silence of over x seconds (say 0.4 seconds is a pause, silences of 0.2-0.5 are often rotations, also worth working to eliminate, so count them too if you want) counts as a pause. Basically pick a timeframe thats longer than it takes to rotate/regrip.
(If you really want to know how long it takes to do a rotation in a real solve, try this: Time yourself doing 5 sunes as fast as you can. Now try do the same again, but put a y/y'/y2/y2' [depending on which movement you are timing, all three are slightly different, y2 sucks most] in between each. Subtract this time from the first time and divide by 4. Thats how long it takes you to do a rotation. More than you thought? For me by this test a y takes around 0.4 seconds, a y2 0.7!. Now imagine doing 4-6 of them in a solve. This is why we work to eliminate....)
Around 0.4 seconds works for me. Make a note of the length in seconds of the total waveform, then go through and cut out all those silences. Now see how long the waveform is. Thats the time it would take for you to solve the cube with your absolute worst TPS if your lookahead was awesome. Not more efficient algs, or increased TPS, just better lookahead. I always find it remarkable how much time there always is to save by being better at looking, not faster at turning.
Also, if you really want to get an accurate measurement of OLL/PLL recognition, just highlight the silence before OLL/PLL is executed and take a note of how long it is. Do this for all the solves and take an average. Voila! Much more accurate and easier to do than counting frames on a youtube video I am sure you will agree. ilikecubing, may I suggest doing this, perhaps for the average you posted, and using the info to guide your work on OLL. Actually let me know if you do because I can compare it to my spreadsheets estimate and perhaps refine the testing methodology if it is not an adequate reflection of the truth.
This simple technique could also help with timing PLLs (find out definitively if you really are sub-1 for all PLLs by checking out the waveform, bye bye arguments about whether the timing methodology is valid), figuring out how much of your 2x2/magic/master solve is pick up and put down rather than actual turning and a bunch of other stuff where fractions of a second are critical.
OK, Im trying to upload the spreadsheet to this thread so other can use it, but when I "go advanced" and click on the attachments button I get a blank pop up window, with no button for browsing, uploading, actually no buttons at all, its just blank. Is this facility down at the moment? (Ive tried Firefox, Opera, and Firefox on another machine). Please help.
Uploading is fixed (thanks A Leman), here is the Beta version of the spreadsheet.
Instructions:
Everything in blue needs filling in, as per instructions given in the thread. There is an area at the top to keep track of your PLL averages, if you don't choose to use this this, overwrite the blue "overall PLL average" box with your average PLL time from whatever other method you choose to use.
Results are at the bottom, as regards interpretation I hope the examples I have given in the thread suffice, although I welcome any questions/queries etc.
This is a test version, I envisage a final product with more bells and whistles. All feedback welcome.
I am also including the document I use to keep track of all my f2l algs from every direction. Basically fill it out with however you solve each of the cases, and then make sure they are as good as they can be. If you use more than 1 rotation (or a y2 at all), find a new alg, if you require 1 rotation for a case, make sure that its better than any of the rotationless ones out there, and if the alg contains more than 8 moves, ensure that it is something that can be executed very quickly [(R U R' U')x3 leaps to mind]. If not, fix that too. I have this printed, and hand write the number of rotations and movecount in the bottom left and right of each box respectively, to quickly find any problem algs. I can then fix them, and my entire f2l is a work in progress as I periodically review and amend my cases.
For alternative algs for each case, check Macky's site http://cubefreak.net/speed/advancedf2l/standard.php or absolutef2l, which is also good. http://f2l.net46.net/. There is a fair bit of crossover between the two, however some good algs appear on one and not the other, so its worth checking both.
Thanks to AbsoluteF2L for the graphics and the idea for the layout.
P.S. Apologies for having to split the f2l doc into two and make it a pdf. This was because I couldn't squeeze the original hires word doc into a small enough file size to upload. If anyone wants the original (bigger graphics and editable) document, please PM and Im happy to email.
Thank you so much for the deep analysis It pretty much sums up my weaknesses and tells me what I should work on
Seeing the analysis,I infer that my F2L is really incosistent,not good but it will hopefully improve with time,but the main thing stopping me from improving is my LL
I never really drilled any algs or anything,I simply learned them and started to use them without caring about their speed.
I need to practice specific PLLs and drill them rigirously to improve in order,try and get all of them fairly sub-2,and also try different fingertricks and better algs to see what suits me best.
Thank you for telling me that my recognition is spot on,since I cursed my recognition on an average solve not knowing that it is the execution which is slow.
I dont use the Rowe E perm yet,thats one PLL I need to change.Else F perm is the T perm one and my N perms are also RUD.So yes,I need to learn the Rowe E perm and drill my F perm and N perms along with V,Rs and Gs.As for OLL,I think I need to change some of my algs.Thanks for the suggestion of timing all of them,that will help me see which ones are really slow.
Thanks you so much for the spreadsheet,I think your method of training is brilliant! It gives a clear indication of wether the cuber is improving or not.
I realize that it's certainly important to be fast at ALL of your algs, but if you're taking such a systematic approach to improvement, shouldn't you factor in the chance of each case?
For example, assuming you are using no "tricks" (like CxLL) to influence PLL, you're far more likely to get a G perm over, say, an N perm.
If your N perm times are slightly above your G perm times (like 5-10%), while it may seem immediately obvious that you should practice on lowering your N perm times. However, theoretically, because of the case distribution, you would actually gain more benefit practicing your G perms.
Obviously there is a cutoff and mathematical relation for these where practicing your N perm would be more beneficial overall, and I'm also not sure how much this actually affects things, but if you are taking such a systematic approach to improvement, I think it'd be an interesting thing to consider.
You make a good point, and this is something I thought about carefully, but ultimately I came down to one conclusion:
A good cuber is a consistent cuber.
Basically, I look at making your worst case solve scenario less bad. In a competition I may get an awkward cross, an F2L I need to rotate for, a dot case (or otherwise tricky) OLL and an N perm. If I can train myself to deal with all that in sub 14 seconds, then I know my average will be sub 14, and more than likely better than that. if I neglect the cases that dont come up that often, you can guarantee they will come up when you dont want them to (Murphys Law). I think improvement by reducing your deficiency in your worst area is better than getting really good at the thing most likely to come up, as your all round skills will steadily improve as each area/alg will come under your examination eventually, and you will end up equally awesome at everything, rather than "Im great unless I get a V-perm". The latter situation is surely less desirable?
I suppose it really comes down to whether you want to lower your global average of 100, but accept that it will still have some sucky times in it (when the awkward comes up, over 100 solves its balanced out by your improved G perms) or reduce the worst case scenario, so no matter what case you get you are decent, and reduce your average that way. I prefer the security of the latter, especially since you get so few solves in competition. My last comp I got a sucky lock up perm (poor execution on my part), thought to myself "no worries, thats the one that will be disregarded in the average" and on the very next solve twisted a corner. Wrecked the whole average. If I were equally good at everything, that couldnt happen. My method works toward that ideal, rather than prioritizing certain things to play the long term odds. Its really about how you define "solid technique". I reckon Faz/Breandan/Cornelius/Matts can sub 10 anything, and thats where I want to be, rather than sub 9 secs 7 times out of 10, with three 11s for the awkward situations I havent practiced enough. You may prefer that, but my system reflects a "good at everything" philosophy.
The mathematical relationship is well defined. I have a spreadsheet that works out your avg PLL by weighting each case as to its relative frequency. I used it for a while, but sucky N perms are still sucky N perms. Fix the worst case at all times and you eliminate all occurrences of sucky. You then are incapable of sucking. This is surely preferable to "statistically unlikely to suck".
In essence, it looks like you can choose two paths then when it comes to practicing algs, and both come with their tradeoffs:
1) Systematically lower your global average as quickly as possible (i.e., "do G perms over N perms").
2) Systematically lower your global average slightly more slowly than path 1, while keeping your standard deviation as low as possible (i.e., "do N perms over G perms").
I'd agree with you that path 2 is probably more desirable in most cases. Interesting.
I do not as of yet have any substantial response to this method, but I will probably be trying this out in the near future(I just took a cubing break, pretty long one, 2-3 months)
But, I am a [Objective-C/Mac OS X] computer programmer so I could program an application to do the calculations. This seems like a pretty simple application, it needs to average some things out, and calculate the average deviation.
If you are interested, please pm me with all your specs and required data.
Yes, I used to be a professional session musician and guitar instructor. Was pretty well known for my technical skills, hence the "speedpicker" handle. And it has certainly influenced my approach to cubing. Don't really play any more though, life moves on....
Yes, I used to be a professional session musician and guitar instructor. Was pretty well known for my technical skills, hence the "speedpicker" handle. And it has certainly influenced my approach to cubing. Don't really play any more though, life moves on....
Sad to hear that, music is a wonderful thing in life.
I have a couple of interests that requires time for practice that I simply can't find enough for. Playing guitar is one of them, had to drop it. Like you said, life goes on.
Cubing is fun too, I find the better you are at something, the more you want to do it and that's what's happening to me. Improving bit by bit every few days is enough to make me keep going.
Wow I need to work on f2l. With my LL time, if f2l was in the same proportion, I would avg 22ish. I currently average 30 ish. I want to get sub-30 and to about 25 for now. My cross would have to be 3 sec and my f2l w/ cross would be 15.5. I have some work to do.
I'll time my PLL's later tonight. As for practice, I think I'll just practice F2L as it's the most time consuming part of a solve 
