Bug#797965: ffmpeg destroys gapless playback on (at least) MP3s

2022-04-28 Thread Christoph Anton Mitterer
Control: reopen -1 Sorry... I had taken other files in my tests before, than what I've used back then. I dug out those now and re-checked again with them.. and while it does work for them with Opus.. it doesn't with MP3. So there's still something in ffmpeg, which destroys the gappless playback

Bug#797965: bs1770gain somehow "destroys" gapless playback on (at least) lame encoded MP3s

2020-02-23 Thread Christoph Anton Mitterer
Controle: retitle -1 ffmpeg destroys gapless playback on (at least) MP3s

Bug#797965: bs1770gain somehow "destroys" gapless playback on (at least) lame encoded MP3s

2020-02-19 Thread Christoph Anton Mitterer
Oh an one further thing... doing: ffmpeg -i in.mp3 -acodec copy -y out.mp3 with both files (i.e. those that should playback gapless) also destroys the gabless playback, that worked just perfectly fine with the files straight from lame. Cheers, Chris.

Bug#797965: bs1770gain somehow "destroys" gapless playback on (at least) lame encoded MP3s

2020-02-19 Thread Christoph Anton Mitterer
Any further ideas on this? I've just checked again with the current ffmpeg/bs1770gain versions from sid... and still, the gapless playback of MP3s is broken when files are processed with --overwrite. It does seem to work when not using --overwrite mode (but -a -o dir),... but that's no big surpri

Bug#797965:

2020-02-13 Thread Julius Willis

Bug#797965: bs1770gain somehow "destroys" gapless playback on (at least) lame encoded MP3s

2019-04-03 Thread Christoph Anton Mitterer
Control: -1 reopen Hey Andreas. I'm afraid I have to reopen this. Today I made a fresh set of extensive checks for gapless playback in mpv (from Debian sid with the ffmpeg from sid) and also upstream git master HEAD ffmpeg alone. The details results can be found here: https://trac.ffmpeg.org/ti

Bug#797965: bs1770gain somehow "destroys" gapless playback on (at least) lame encoded MP3s

2016-10-18 Thread Andreas Cadhalpun
Control: tags -1 fixed-upstream Hi Cris, On 29.06.2016 21:56, Christoph Anton Mitterer wrote: > Andreas, anything new on this? What happened to your proposed patch? Jon Toohill managed to write a proper patch for this and it is now fixed upstream [1]. Best regards, Andreas 1: https://git.vid

Bug#797965: bs1770gain somehow "destroys" gapless playback on (at least) lame encoded MP3s

2016-06-30 Thread Sebastian Ramacher
[Mails to nnn...@bugs.debian.org do not reach the submitter. Explicitly CC-ing Christoph] On 2016-06-30 02:48:24, Carl Eugen Hoyos wrote: > Hi! > > If you want me to forward this bug to other FFmpeg developers, please: > * Provide sample(s) that allow to reproduce the issue > and > * The ffmpeg c

Bug#797965: bs1770gain somehow "destroys" gapless playback on (at least) lame encoded MP3s

2016-06-29 Thread Carl Eugen Hoyos
Hi! If you want me to forward this bug to other FFmpeg developers, please: * Provide sample(s) that allow to reproduce the issue and * The ffmpeg command line that allows to reproduce the issue together with the complete, uncut console output and * explain what is wrong with the output file. I

Bug#797965: bs1770gain somehow "destroys" gapless playback on (at least) lame encoded MP3s

2016-03-25 Thread Carl Eugen Hoyos
Hi! If I understand correctly, no sample and no command line including complete, uncut console output was ever provided for this bug report. If this is correct, please close as needs-more-information. Thank you, Carl Eugen

Bug#797965: bs1770gain somehow "destroys" gapless playback on (at least) lame encoded MP3s

2015-12-22 Thread Andreas Cadhalpun
Hi, On 19.12.2015 23:55, Christoph Anton Mitterer wrote: > On Sat, 2015-12-19 at 23:24 +0100, Andreas Cadhalpun wrote: >> Now I'm a bit skeptical about "LAME adding some special tags". > IIRC, the LAME tag isn't actually an ID3 tag, but padded in some other > parts of the MP3 header which aren't u

Bug#797965: bs1770gain somehow "destroys" gapless playback on (at least) lame encoded MP3s

2015-12-19 Thread Peter Belkner
On 19.12.2015 23:24, Andreas Cadhalpun wrote: Now I'm a bit skeptical about "LAME adding some special tags". You've used lame with '--id3v2-utf16 --add-id3v2 --id3v1-only'. What is this supposed to do? Add id3v1 tags, or id3v2 or both? AFAIK it's the so called LAME or XING header. I myself was

Bug#797965: bs1770gain somehow "destroys" gapless playback on (at least) lame encoded MP3s

2015-12-19 Thread Christoph Anton Mitterer
On Sat, 2015-12-19 at 23:24 +0100, Andreas Cadhalpun wrote: > OK, so the problem is that after remuxing with ffmpeg, there is > a barely audible ... gap ... between the two files, right? Yes > Now I'm a bit skeptical about "LAME adding some special tags". IIRC, the LAME tag isn't actually an ID3 t

Bug#797965: bs1770gain somehow "destroys" gapless playback on (at least) lame encoded MP3s

2015-12-19 Thread Andreas Cadhalpun
Control: tags -1 - moreinfo + confirmed Hi, On 19.12.2015 21:09, Christoph Anton Mitterer wrote: > You need two WAV files, which contain seamlessly playing sound (e.g. > just take any song and split it in the middle). > > For lossless formats, there is typically no problem, that these two > play

Bug#797965: bs1770gain somehow "destroys" gapless playback on (at least) lame encoded MP3s

2015-12-19 Thread Christoph Anton Mitterer
On Sat, 2015-12-19 at 21:05 +0100, Andreas Cadhalpun wrote: > Unless you can reproduce this with ffmpeg's test sample (in which > case, please elaborate what the problem is), please send my privately > (a link to) a small sample. Wait a few minutes... smime.p7s Description: S/MIME cryptographic si

Bug#797965: bs1770gain somehow "destroys" gapless playback on (at least) lame encoded MP3s

2015-12-19 Thread Peter Belkner
On 19.12.2015 20:47, Andreas Cadhalpun wrote: Control: tags -1 moreinfo Hi, On 19.12.2015 20:40, Petter Reinholdtsen wrote: As the bs1770gain developer Peter Belkner explain, this issue is really an issue in ffmpeg and not in bs1770gain. Because of this, I reassign it to ffmpeg. Can you prov

Bug#797965: bs1770gain somehow "destroys" gapless playback on (at least) lame encoded MP3s

2015-12-19 Thread Andreas Cadhalpun
On 19.12.2015 21:05, Peter Belkner wrote: > > > On 19.12.2015 20:59, Andreas Cadhalpun wrote: >> Hi Peter, >> >> On 19.12.2015 20:53, Peter Belkner wrote: >>> On 19.12.2015 20:47, Andreas Cadhalpun wrote: On 19.12.2015 20:40, Petter Reinholdtsen wrote: > As the bs1770gain developer Peter

Bug#797965: bs1770gain somehow "destroys" gapless playback on (at least) lame encoded MP3s

2015-12-19 Thread Christoph Anton Mitterer
On Sat, 2015-12-19 at 20:59 +0100, Andreas Cadhalpun wrote: > I might be missing what the problem is, but this command seems to > work > just fine with ffmpeg's test sample [1]. > Can you confirm this, or describe more precisely what the problem is? You need two WAV files, which contain seamlessly

Bug#797965: bs1770gain somehow "destroys" gapless playback on (at least) lame encoded MP3s

2015-12-19 Thread Andreas Cadhalpun
On 19.12.2015 20:59, Christoph Anton Mitterer wrote: > On Sat, 2015-12-19 at 20:47 +0100, Andreas Cadhalpun wrote: >> Can you provide a sample for reproducing this problem? > Providing samples is always a bit problematic for copyrightreasons, > especially when providing them publicly. > > Any CD-D

Bug#797965: bs1770gain somehow "destroys" gapless playback on (at least) lame encoded MP3s

2015-12-19 Thread Peter Belkner
On 19.12.2015 20:59, Andreas Cadhalpun wrote: Hi Peter, On 19.12.2015 20:53, Peter Belkner wrote: On 19.12.2015 20:47, Andreas Cadhalpun wrote: On 19.12.2015 20:40, Petter Reinholdtsen wrote: As the bs1770gain developer Peter Belkner explain, this issue is really an issue in ffmpeg and not

Bug#797965: bs1770gain somehow "destroys" gapless playback on (at least) lame encoded MP3s

2015-12-19 Thread Christoph Anton Mitterer
On Sat, 2015-12-19 at 20:47 +0100, Andreas Cadhalpun wrote: > Can you provide a sample for reproducing this problem? Providing samples is always a bit problematic for copyrightreasons, especially when providing them publicly. Any CD-DA, which has gapless tracks (e.g. typically live CDs) will do. I

Bug#797965: bs1770gain somehow "destroys" gapless playback on (at least) lame encoded MP3s

2015-12-19 Thread Andreas Cadhalpun
Hi Peter, On 19.12.2015 20:53, Peter Belkner wrote: > On 19.12.2015 20:47, Andreas Cadhalpun wrote: >> On 19.12.2015 20:40, Petter Reinholdtsen wrote: >>> As the bs1770gain developer Peter Belkner explain, this issue is >>> really an issue in ffmpeg and not in bs1770gain. Because of this, I >>> r

Bug#797965: bs1770gain somehow "destroys" gapless playback on (at least) lame encoded MP3s

2015-12-19 Thread Christoph Anton Mitterer
On Sat, 2015-12-19 at 20:40 +0100, Petter Reinholdtsen wrote: > As the bs1770gain developer Peter Belkner explain, this issue is > really an issue in ffmpeg and not in bs1770gain.  Because of this, I > reassign it to ffmpeg. Well I think it's still also some kind of a design issue. The problem is

Bug#797965: bs1770gain somehow "destroys" gapless playback on (at least) lame encoded MP3s

2015-12-19 Thread Andreas Cadhalpun
Control: tags -1 moreinfo Hi, On 19.12.2015 20:40, Petter Reinholdtsen wrote: > As the bs1770gain developer Peter Belkner explain, this issue is > really an issue in ffmpeg and not in bs1770gain. Because of this, I > reassign it to ffmpeg. Can you provide a sample for reproducing this problem?

Bug#797965: bs1770gain somehow "destroys" gapless playback on (at least) lame encoded MP3s

2015-12-19 Thread Petter Reinholdtsen
Control: reassign -1 libavformat-dev Control: found -1 7:2.8.3-1 Control: affects -1 bs1770gain As the bs1770gain developer Peter Belkner explain, this issue is really an issue in ffmpeg and not in bs1770gain. Because of this, I reassign it to ffmpeg. -- Happy hacking Petter Reinholdtsen

Bug#797965: [Peter Belkner] Re: BS1770GAIN

2015-09-14 Thread Petter Reinholdtsen
--- Begin Message --- ffmpeg -i -acodec copy -y erases gapless. Regards On 10.09.2015 20:32, Petter Reinholdtsen wrote: > [Peter Belkner] >> Because bs1770gain is not supposed to have a myriad of backends to >> deal with. It should be just one: FFmpeg. >> >> The hope is that one day FFmpeg wi

Bug#797965: BS1770GAIN

2015-09-10 Thread Petter Reinholdtsen
[Peter Belkner] > Because bs1770gain is not supposed to have a myriad of backends to > deal with. It should be just one: FFmpeg. > > The hope is that one day FFmpeg will have fixed their errors. They > are the experts for those myriads of formats and codecs. > > Please file these errors under FFm

Bug#797965: BS1770GAIN

2015-09-05 Thread Peter Belkner
On 04.09.2015 23:02, Christoph Anton Mitterer wrote: @Peter: Why exactly do you need to use ffmpeg for writing? Shouldn't it be enough to write some tags? Because bs1770gain is not supposed to have a myriad of backends to deal with. It should be just one: FFmpeg. The hope is that one day FF

Bug#797965: BS1770GAIN

2015-09-04 Thread Christoph Anton Mitterer
Peter (=upstream) has asked me off list to check whether: $ ffmpeg -i in.mp3 -acodec copy -y out.mp3 also makes the resulting files having gaps. The back story is that bs1770gain apparently somehow uses ffmpeg. And the answer is yes, after copying the files as above with ffmpeg, they have gaps whe

Bug#797965: bs1770gain somehow "destroys" gapless playback on (at least) lame encoded MP3s

2015-09-03 Thread Christoph Anton Mitterer
Package: bs1770gain Version: 0.4.5-1+b1 Severity: important Tags: upstream Hi. It seems that bs1770gain somehow "destroys" gapless playback on (at least) lame encoded MP3s. For example, when I encode gapless WAV files via e.g.: lame --verbose -q 0 -v -V 3 --noreplaygain --id3v2-utf16 --add-id3v