ffmpeg/tests/ref/fate/gapless-mp3

d5c88cf38416329a052a9b0cb140fb4c *tests/data/fate/gapless-mp3.out-1
c96c3ae7bd3300fd2f4debac222de5b7
3386bc2009b31b7ef39247918cbb02a5 *tests/data/fate/gapless-mp3.out-2
c96c3ae7bd3300fd2f4debac222de5b7
3ce35ec2a9a59b7459ecd6c98d8fa123 *tests/data/fate/gapless-mp3.out-3
fate: add mp3 gapless test Signed-off-by: Michael Niedermayer <michaelni@gmx.at> 2015-04-15 21:10:49 +02:00			`d5c88cf38416329a052a9b0cb140fb4c *tests/data/fate/gapless-mp3.out-1`
avcodec/mpegaudiodec_template: use double to build csa tables Fixes rounding difference between 32bit x86 and 64bit Fixes fate failure with gapless mp3 Signed-off-by: Michael Niedermayer <michaelni@gmx.at> 2015-04-17 13:36:14 +02:00			`c96c3ae7bd3300fd2f4debac222de5b7`
fate: gapless: fix mp3 tests Seeking to a negative time did not have the desired effect of seeking to the next valid position (the file start). On the other hand, just "-ss 0" will normally seek to a position higher than 0, because it adds the start time of the file. (The start time is not 0 because the gapless code skips a few samples from the start.) Fix this by using the "-seek_timestamp 1" option, which makes "-ss 0" do what you'd expect it would do. Also put the -ss option at the right place, before -i. This actually makes it seek, instead of something completely else. The ".out-3" test is no different in the -usetoc 0/1 cases, because the seeking is inaccurate (in both cases). Signed-off-by: Michael Niedermayer <michaelni@gmx.at> 2015-04-20 19:36:52 +02:00			`3386bc2009b31b7ef39247918cbb02a5 *tests/data/fate/gapless-mp3.out-2`
avcodec/mpegaudiodec_template: use double to build csa tables Fixes rounding difference between 32bit x86 and 64bit Fixes fate failure with gapless mp3 Signed-off-by: Michael Niedermayer <michaelni@gmx.at> 2015-04-17 13:36:14 +02:00			`c96c3ae7bd3300fd2f4debac222de5b7`
avcodec/mpegaudio_parser: Discard ID3v1 tag at the end Ideally this should be discarded by the demuxer but this is not possible without fully parsing which would be then very similar to this. The current ID3v1 discard code in the demuxer does not work and will be removed in a subsequent commit The discard code could be adjusted if needed to also discard tags at other locations than the end or to limit this possibly to input from the mp3 demuxer or even to move the discarding to the decoder. Signed-off-by: Michael Niedermayer <michaelni@gmx.at> 2015-06-24 02:37:58 +02:00			`3ce35ec2a9a59b7459ecd6c98d8fa123 *tests/data/fate/gapless-mp3.out-3`