You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I was researching the non-linear 12-bit sample format used for the DAT LP mode (and for DV video as well) when I noticed that there are a couple of different conversion strategies used in different software packages out there. The LUT in your code seems to have been generated using the same algorithm used in DATlib and VLC. One characteristic of this method is that the positive and negative value ranges of the resulting signed 16-bit integer are non-symmetrical (-32768..32704) which might cause some distortion (correct me if I'm wrong here).
The difference between the two algorithms is whether 0s or 1s get shifted in from the right for negative values. Both seem to be valid solutions according to patent US5325240A since the shifted in values are basically "don't cares".
I was researching the non-linear 12-bit sample format used for the DAT LP mode (and for DV video as well) when I noticed that there are a couple of different conversion strategies used in different software packages out there. The LUT in your code seems to have been generated using the same algorithm used in DATlib and VLC. One characteristic of this method is that the positive and negative value ranges of the resulting signed 16-bit integer are non-symmetrical (-32768..32704) which might cause some distortion (correct me if I'm wrong here).
I've found that FFmpeg / libavcodec uses a different algorithm which results in symmetrical ranges (-32705..32704):
https://github.com/FFmpeg/FFmpeg/blob/3778b1f6f102c7fda82b83f19db0bf48151d496b/libavcodec/dvaudiodec.c#L68
I've re-created the LUT using FFmpeg's algorithm - the corresponding patch is attached:
ffmpeg-conv.patch
The text was updated successfully, but these errors were encountered: