Add --progress_bar flag to control progress bar visibility

[NITHIVARSHATP-07]

This pull request adds a new optional CLI flag --progress_bar to the Whisper transcription script.
The flag gives users control over whether or not the progress bar is displayed during transcription.

[ryanheise]

Out of curiosity, what is the use case for disabling the progress bar?

[NITHIVARSHATP-07]

Out of curiosity, what is the use case for disabling the progress bar?

Thanks for the question! The main use case is for automated or non-interactive environments — like CI/CD pipelines, scripts, or log files — where a dynamic progress bar can clutter the output or break formatting. This flag gives users control to disable the progress bar and keep output clean in those scenarios.

[ryanheise]

I see, although wouldn't the transcript progress also be noisy in the output, not only the progress bar?

[NITHIVARSHATP-07]

I see, although wouldn't the transcript progress also be noisy in the output, not only the progress bar?

That's a great point — yes, the transcript output can also be noisy in certain contexts. That’s why the design separates both controls: --verbose governs whether transcripts are printed, while --progress_bar handles the visual progress bar. This gives users fine-grained control — for example, they can suppress both for clean logs, or enable just one depending on their use case.

[ryanheise]

That is exactly why I was curious about your use case - what is your context in which you want to hide the progress bar, but you don't want to hide the transcript progress, both of which is progress? If you have a dependency on parts of the progress, this would seem fragile, so I wondered what your use case is.

[NITHIVARSHATP-07]

That is exactly why I was curious about your use case - what is your context in which you want to hide the progress bar, but you don't want to hide the transcript progress, both of which is progress? If you have a dependency on parts of the progress, this would seem fragile, so I wondered what your use case is.

That’s a great question — I really appreciate the thoughtful follow-up. The idea behind separating --progress_bar from --verbose is to give users more granular control over output formatting. Not all environments treat “progress” the same way.

For instance, someone might want to log only the transcript (e.g., piping it to a file or post-processing it), while suppressing the live progress bar — which can cause artifacts in logs or break formatting in non-TTY environments.

The goal isn't to rely on progress bar data itself, but to keep output clean and compatible in scripting scenarios, where the transcript is the primary deliverable and the progress bar is purely visual.

That said, I completely agree — using both flags together (--verbose and --progress_bar) provides the clearest and most robust behavior.

[ryanheise]

The goal isn't to rely on progress bar data itself, but to keep output clean and compatible in scripting scenarios, where the transcript is the primary deliverable and the progress bar is purely visual.

As mentioned above, the progress bar and the transcript progress are both progress and hence both purely visual. These are both intended for human eyes, and it would be fragile for a script to depend on their format. I am still interested therefore to know what your own use case, i.e. the use case that specifically motivates you to depend on the transcript progress output, as there may be a better way to tackle it. Are you post-processing the transcript progress display? If so, what specifically are you using the transcript progress for that you can't otherwise get directly from the transcript output rather than the transcript progress display? Knowing that, this could lead to an idea about a lacking feature that could be added to the API.

[NITHIVARSHATP-07]

As mentioned above, the progress bar and the transcript progress are both progress and hence both purely visual. These are both intended for human eyes, and it would be fragile for a script to depend on their format. I am still interested therefore to know what your own use case, i.e. the use case that specifically motivates you to depend on the transcript progress output, as there may be a better way to tackle it. Are you post-processing the transcript progress display? If so, what specifically are you using the transcript progress for that you can't otherwise get directly from the transcript output rather than the transcript progress display? Knowing that, this could lead to an idea about a lacking feature that could be added to the API.

Thanks again for the follow-up — I really appreciate how you're thinking through this. To clarify: I’m not parsing the transcript progress output or relying on it structurally. My motivation was primarily to keep logs clean in scripting and automation contexts.
In those cases, the transcript output is still useful for later review or post-processing, but the dynamic progress bar can clutter logs or break formatting when output is redirected — especially in non-TTY environments. So the goal was simply to allow toggling it independently, without introducing any reliance on visual output.
That said, I completely agree that parsing visual output is fragile, and I appreciate you pointing that out. My intention was just to give users a bit more flexibility to control cosmetic output where clarity matters.
Out of curiosity — I’d definitely be interested in a cleaner API-level way to access intermediate transcript progress, if that’s something worth exploring in the future.

[ryanheise]

In those cases, the transcript output is still useful for later review or post-processing

That is actually what I was asking about - do you have a use case for post-processing the transcript progress display?

[NITHIVARSHATP-07]

That is actually what I was asking about - do you have a use case for post-processing the transcript progress display?

Got it — thanks for clarifying! No, I'm not doing any post-processing on the transcript progress display. I’m only aiming to suppress the visual progress bar to keep logs clean, while still allowing the transcript output to appear as usual. I'm not relying on its structure or parsing it in any way.
That said, I’d definitely be interested in a cleaner API-level way to access intermediate transcript updates in the future, especially for cases where partial results might be useful for streaming or early feedback.