Incorrect right stride when sequence end falls within right stride of penultimate chunk
### System Info

- `transformers` version: 4.26.0
- Platform: Linux-4.14.301-224.520.amzn2.x86_64-x86_64-with-glibc2.26
- Python version: 3.9.15
- Huggingface_hub version: 0.12.0
- PyTorch version (GPU?): 1.11.0 (False)
- Tensorflow version (GPU?): 2.7.1 (False)
- Flax version (CPU?/GPU?/TPU?): not installed (NA)
- Jax version: not installed
- JaxLib version: not installed
- Using GPU in script?: No
- Using distributed or parallel set-up in script?: No

### Who can help?

@ArthurZucker @sanchit-gandhi @Narsil

### Information

- [ ] The official example scripts
- [X] My own modified scripts

### Tasks

- [X] An officially supported task in the `examples` folder (such as GLUE/SQuAD, ...)
- [ ] My own task or dataset (give details below)

### Reproduction

The easiest way to see this problem is to use a Whisper ASR model and debug into the `chunk_iter` method of `transformers/src/transformers/pipelines/automatic_speech_recognition.py` with an audio file that is of a specific length. An example length that illustrates this problem is about 87 seconds in length. The specific file I was testing with had 1,385,995 samples at 16kHz.

### Expected behavior

The Whisper model requires chunks of 30 seconds in length. I tested using the default stride of 5 seconds on each side. So a chunk is `30*16,000=480,000` samples. The stride width is normally `5*16,000=80,000 `samples. But the first chunk doesn't have a left stride and the final chunk doesn't have a right stride so, for this file we would expect the following chunk sizes and strides...

* 480,000; 0; 80,000
* 480,000; 80,000; 80,000
* 480,000; 80,000; 80,000
* 425,995; 80,000; **25,995**
* 105,995; 80,000; 0

But what we actually get is

* 480,000; 0; 80,000
* 480,000; 80,000; 80,000
* 480,000; 80,000; 80,000
* 425,995; 80,000; **80,000**
* 105,995; 80,000; 0

This means that the fourth (penultimate) chunk is processed as if it has a full right stride when in fact it shouldn't.

> if it has a full right stride when in fact it shouldn't.

The striding is designed in such a way that right stride should *always* be full, or if there's not enough data, no right stride at all and you are the last item.

There could still be a bug like you describe.<|||||>1,385,995

Using chunk_stride `(480, 80, 80)` means we're going to effectively use only 320k samples for each chunk so we're going to move only 320k samples within the audio at each step (except first and last which just use more audio)

First chunk:
(480, 0, 80), starting at offset 0 within samples
(480, 80, 80), starting at offset 320 within samples (80 left stride, means we're effectively using data from 400)
(480, 80, 80), starting at offset 640 within samples
(425, 80, 0), starting at offset 960 within samples (finishing at 1 385k)

The 4th one should be the last one, since the last sample to consider is outside the range of the audio, so it is the last part of the audio.

That is what should happen I think.<|||||>I'm seeing this:

```
(480000, 80000, 80000)
(480000, 80000, 80000)
(425000, 80000, 80000)
(105000, 80000, 0)
```

So there definitely seems to be an issue. 

https://github.com/huggingface/transformers/blob/main/src/transformers/pipelines/automatic_speech_recognition.py#L66

This line could be the issue, but I'm not fresh enough right now to be sure that my current reasoning is solid.