Banding will not have come about because of the FEC counter, but the FEC counter does, indirectly, show what has caused banding to happen. It is all a bit chicken-or-egg.
Your banding will have come about because of DLM intervention: in fact, banding represents quite a severe level of intervention, used when the first few mechanisms have failed to improve the situation.
DLM will have been triggered to intervene, in turn, because of the number of errors seen on your line - which are caused by noise, and can be seen seen by the CRC counter (or the OHFerr counter; same thing). DLM doesn't care about the actual CRC count directly; it really cares about how those CRC errors are spread out over time - so it monitors the rate of Errored Seconds (ES), watching for it to exceed a "red" threshold level in 24 hours. The actual threshold value changes, depending on the setting of the speed/stability requirement, which depends on way your ISP ordered the line from BTW/Openreach. For Plusnet customers, on the speediest setting, the ES threshold is 2880 in 24 hours. For TalkTalk, on the middle stability level, the ES threshold appears to be 1440 in 24 hours. There is one further, more stable, setting that probably has a threshold of 720 ES's per day.
An ES count above this "red" threshold, for a single day, will normally trigger DLM to intervene. Once DLM has intervened, it will usually have turned the FEC error correction process on - with the aim of trapping the errors and automatically correcting them - and will usually turn interleaving on too, to make FEC more effective.
Any more days above the "red" threshold will cause DLM to re-intervene more deeply.
Once the FEC process is running and tuned correctly (possibly in combination with banding), most bursts of noise on the line, which would have gone to cause a CRC error, will be corrected and become FEC events instead (so the FEC counter is not a count of errors, but a count of fixes). If a burst of noise is bad enough, the FEC process cannot correct it, and the error will become a CRC event instead, and affect the ES counter as normal. A properly-tuned FEC process will reduce the CRC counter and the ES rate by one or more orders of magnitude.
So, now that you are measuring your line, the FEC counter that you can see is an indication of the errors that have been fixed by the FEC process. They show where a burst of noise happened, and where CRC errors would have happened if FEC hadn't been turned on by DLM intervention.
So your line's problems are indeed shown up by the FEC counter, but aren't directly caused by it.
Getting DLM to de-intervene then follows this process in reverse to remove banding, or to turn off FEC, but DLM is conservative in the extreme. You have to show repeated "good" days for it to relent...
In reverse, the ES counter needs to be below a "green" threshold; where the "red" threshold was 2880/day, the "green" threshold is 288/day - so the ES counter needs to be less than this - but for multiple days. A reduced ES count suggests to DLM that your problem has gone away, so it should relent. Quite often, a reduced ES count goes hand-in-hand with a reduced FEC rate.
Now the tricky part, as the whole process isn't very public...
Imagine a case where the FEC process is tuned perfectly - every burst of noise is corrected by FEC - but is needed very badly, as noise is prevalent. In this case, there will be a significant FEC count, but a zero CRC and ES count. If DLM relented here, it would be the wrong thing to do.
Thus some people believe that for DLM to de-intervene, it needs both the ES level to be below the "green" threshold, and it also requires the FEC rate to be limited somewhat. However, no-one knows if this is true, and if it were, what the FEC thresholds would be.
So the short answer to your question is that DLM will indeed reduce/remove banding, and remove FEC/interleaving, once the noise is reduced so it causes fewer CRC errors.
