#7243 closed defect (invalid)
Supplying redudant arguments changes actual ouput response
| Reported by: | joblow | Owned by: | |
|---|---|---|---|
| Priority: | normal | Component: | undetermined |
| Version: | unspecified | Keywords: | |
| Cc: | Blocked By: | ||
| Blocking: | Reproduced by developer: | no | |
| Analyzed by developer: | no |
Description
By adding these command line values for reading a 16-bit 44100hz wav file causes the data to be subtle altered.
-af atempo=44100 -ar 1
It seems that the resampler is not perfectly accurate(could be edge noise) and it does not check to see if it doesn't even have to resample. Or it could be the rate.
The code should not process the data for rate change if the rate is 1. If the sample rate is the same as the source it should not try to resample.
Change History (8)
comment:1 by , 6 years ago
comment:2 by , 6 years ago
I, obviously, meant -af atempo=1 -ar 44100. (it is obvious because if the values were truly reverse then there would be no subtle alteration)
comment:3 by , 6 years ago
| Resolution: | → invalid |
|---|---|
| Status: | new → closed |
The atempo filter is designed that way.
The -ar command insert aresample filter, and it alone give exact same audio output.
comment:4 by , 6 years ago
| Component: | ffmpeg → undetermined |
|---|
comment:5 by , 6 years ago
So, what you are saying that when one supply a rate change of 1, which is no rate change at all, that it is ok for ffmpeg to alter the data? This is non sense! I guess someone just wants to get out of fixing the bug!
comment:6 by , 6 years ago
It is not bug, filter is designed that way, also filter is pretty obsolete, but others dev oposed new/better filter addition for doing same operation.
comment:7 by , 6 years ago
There is absolutely no way you can make sense when you say it is designed that way... if it were it was designed wrong and you cannot justify it being wrong by saying it was right.
A range change by a factor of 1 is NO CHANGE! That is what 1x means, it means no change! Now, if it means no change then why the hell is it changing the data?!?!
To stay that it was designed to do that is ignorant. The code to fix it is very simple:
if (rate == 1) return data; else return changeRate(rate, data);
What you are doing is starting from your conclusion that because the filter behaves that way that it was designed right then concluding that this it behaves correctly. That is ignorant logic.
Your ffmpeg command is invalid.