Bug#797965: bs1770gain somehow "destroys" gapless playback on (at least) lame encoded MP3s
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.videolan.org/?p=ffmpeg.git;a=commitdiff;h=3b02f6dd7be880fd6c1bcaf2fd0c1314dcee7aa6 ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Processed: Re: Bug#797965: bs1770gain somehow "destroys" gapless playback on (at least) lame encoded MP3s
Processing control commands: > tags -1 fixed-upstream Bug #797965 [libavformat-dev] bs1770gain somehow "destroys" gapless playback on (at least) lame encoded MP3s Added tag(s) fixed-upstream. -- 797965: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=797965 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Bug#797965: bs1770gain somehow "destroys" gapless playback on (at least) lame encoded MP3s
[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 command line that allows to reproduce the issue together with > the complete, uncut console output > and > * explain what is wrong with the output file. > > If you cannot (or don't want to) provide all three, I suggest to close this > bug because I don't see how it can be fixed without it. > (Or at least it wouldn't be known on this bug tracker if the issue ever gets > fixed.) > > If the issue is not reproducible with the ffmpeg command line tool but only > for an API user, things get more complicated but in this case you should try > hard to rule out a bug in the tool using the API. > > Carl Eugen > > ___ > pkg-multimedia-maintainers mailing list > pkg-multimedia-maintainers@lists.alioth.debian.org > http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers -- Sebastian Ramacher signature.asc Description: PGP signature ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Bug#797965: bs1770gain somehow "destroys" gapless playback on (at least) lame encoded MP3s
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. If you cannot (or don't want to) provide all three, I suggest to close this bug because I don't see how it can be fixed without it. (Or at least it wouldn't be known on this bug tracker if the issue ever gets fixed.) If the issue is not reproducible with the ffmpeg command line tool but only for an API user, things get more complicated but in this case you should try hard to rule out a bug in the tool using the API. Carl Eugen ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Bug#797965: bs1770gain somehow "destroys" gapless playback on (at least) lame encoded MP3s
Hey. Andreas, anything new on this? What happened to your proposed patch? Carl: - The command lines are given in the initial mail of this bug. - IIRC a sample link was provided somewhere as well, but if that doesn't suit you, simply take *any* wav file on earth, split it in two halfs a a position with sound, encode the resulting files with e.g. lame, process it with bs1770gain (and thus ffmpeg) and then you'll see how the gapless information gets destroyed. - As for logs, this is always a bit tedious,... I did provide such logs in other bugs I've opened at ffmpeg upstream about gapless playback issues, with never any clear outcome. Since ffmpeg has quite some development pace, any such logs would be useless few weeks after I've posted them. If a developer actually looks into that issue, I can of course provide such logs, but since this is a general bug, it's really very easy to create sample files and logs oneself. I'd say it doesn't take 5 mins, and for an audio developer probably even less. Cheers, Chris. smime.p7s Description: S/MIME cryptographic signature ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Bug#797965: bs1770gain somehow "destroys" gapless playback on (at least) lame encoded MP3s
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 ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Bug#797965: bs1770gain somehow "destroys" gapless playback on (at least) lame encoded MP3s
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 used. > http://gabriel.mp3-tech.org/mp3infotag.html > http://wiki.hydrogenaud.io/index.php?title=LAME#VBR_header_and_LAME_tag > http://libzplay.sourceforge.net/LAMETAG.html Thanks for this clarification. I was indeed confused by the ID3 tags mentioned in the initial report. > What I would assume that ffmpeg does, is, that it simply drops or > somehow mangles up the LAMEtag,... or actually modifies the audio > stream so that it doesn't fit to the LAMEtag anymore. Indeed, FFmpeg parses the XING/LAME header when demuxing and then writes a new one when muxing. On 20.12.2015 06:52, Peter Belkner wrote: > AFAIK it's the so called LAME or XING header. > I myself was adding the first version of it to FFmpeg some time ago Oh cool! What a coincidence! > but unfortunately not based on my proposal (just copy it) but the way > the FFmpeg team wants to have it. Meanwhile it's changed anyway. Well, simply copying would have its problems, e.g. if it's actually transcoded, the copied header would most likely be quite wrong... On the other hand, parsing the header has its own problems, as this bug shows: While the demuxer reads the correct gapless values from the XING/LAME header, they are never propagated to the muxer and not written to the output. I've hacked together a patch[1] that makes this work, but don't get too excited: It can't be committed as is, because it uses private libavformat fields outside of libavformat. Best regards, Andreas 1: https://ffmpeg.org/pipermail/ffmpeg-devel/2015-December/185657.html ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Bug#797965: bs1770gain somehow "destroys" gapless playback on (at least) lame encoded MP3s
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 ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Bug#797965: bs1770gain somehow "destroys" gapless playback on (at least) lame encoded MP3s
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-DA, which has gapless tracks (e.g. typically live CDs) will do. > If you don't have access to any, contact me off list. 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. Best regards, Andreas ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Bug#797965: bs1770gain somehow "destroys" gapless playback on (at least) lame encoded MP3s
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 in bs1770gain. Because of this, I reassign it to ffmpeg. Can you provide a sample for reproducing this problem? Any ffmpeg -i -acodec copy -y should do it. 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? The problem is not mine but the one of Andreas Cadhalpun. You should discuss it with him. Best regards, Andreas 1: https://fate-suite.ffmpeg.org/gapless/gapless.mp3 ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Bug#797965: bs1770gain somehow "destroys" gapless playback on (at least) lame encoded MP3s
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 signature ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Bug#797965: bs1770gain somehow "destroys" gapless playback on (at least) lame encoded MP3s
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? Best regards, Andreas ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Processed: Re: Bug#797965: bs1770gain somehow "destroys" gapless playback on (at least) lame encoded MP3s
Processing control commands: > tags -1 moreinfo Bug #797965 [libavformat-dev] bs1770gain somehow "destroys" gapless playback on (at least) lame encoded MP3s Added tag(s) moreinfo. -- 797965: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=797965 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Bug#797965: bs1770gain somehow "destroys" gapless playback on (at least) lame encoded MP3s
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 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 back again seamless (typically called "gapless"). When encoding them to lossy formats however, things get more tricky. Different format provides for different means of gapless playback (or none at all). MP3 has e.g. two widespread ways, one by mean of LAME adding some special tags, and itunes has something similar. Opus/Vorbis/AAC, have similar things. The problem was now, that when such gaplessly encoded files were processed with bs1770gain, they were no longer gapless afterwards. Peter thinks, due to a problem in the copy mode of ffmpeg. If it's really that, and if you just do ffmpeg copy one one file, you won't probably hear it... even when two audio files that belong together, you may need to listen *very* closely to hear a gap. Cheers, Chris. smime.p7s Description: S/MIME cryptographic signature ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Bug#797965: bs1770gain somehow "destroys" gapless playback on (at least) lame encoded MP3s
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 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? >>> Any >>> >>> ffmpeg -i -acodec copy -y >>> >>> should do it. >> 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? > > The problem is not mine but the one of Andreas Cadhalpun. You should discuss > it with him. I guess you wanted to say Christoph Anton Mitterer... Best regards, Andreas ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Bug#797965: bs1770gain somehow "destroys" gapless playback on (at least) lame encoded MP3s
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 provide a sample for reproducing this problem? Any ffmpeg -i -acodec copy -y should do it. Best regards, Andreas ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Bug#797965: bs1770gain somehow "destroys" gapless playback on (at least) lame encoded MP3s
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 that ffmpeg, by nature a encoder/decoder, is always more likely to actually change the different streams, than if the application would just write to the respective meta-data/tags areas of the file in question. I also thought there would be quite a number of libs, which serve as a more or less general purpose tagging lib. Cheers, Chris. smime.p7s Description: S/MIME cryptographic signature ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Bug#797965: bs1770gain somehow "destroys" gapless playback on (at least) lame encoded MP3s
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. If you don't have access to any, contact me off list. Cheers, Chris. smime.p7s Description: S/MIME cryptographic signature ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Bug#797965: bs1770gain somehow "destroys" gapless playback on (at least) lame encoded MP3s
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 >>> reassign it to ffmpeg. >> Can you provide a sample for reproducing this problem? > > Any > > ffmpeg -i -acodec copy -y > > should do it. 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? Best regards, Andreas 1: https://fate-suite.ffmpeg.org/gapless/gapless.mp3 ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Processed: Re: Bug#797965: bs1770gain somehow "destroys" gapless playback on (at least) lame encoded MP3s
Processing control commands: > tags -1 - moreinfo + confirmed Bug #797965 [libavformat-dev] bs1770gain somehow "destroys" gapless playback on (at least) lame encoded MP3s Removed tag(s) moreinfo. Bug #797965 [libavformat-dev] bs1770gain somehow "destroys" gapless playback on (at least) lame encoded MP3s Added tag(s) confirmed. -- 797965: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=797965 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Bug#797965: bs1770gain somehow "destroys" gapless playback on (at least) lame encoded MP3s
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 back again seamless (typically called "gapless"). > > When encoding them to lossy formats however, things get more tricky. > Different format provides for different means of gapless playback (or > none at all). > MP3 has e.g. two widespread ways, one by mean of LAME adding some > special tags, and itunes has something similar. > Opus/Vorbis/AAC, have similar things. > > The problem was now, that when such gaplessly encoded files were > processed with bs1770gain, they were no longer gapless afterwards. > > Peter thinks, due to a problem in the copy mode of ffmpeg. > > If it's really that, and if you just do ffmpeg copy one one file, you > won't probably hear it... even when two audio files that belong > together, you may need to listen *very* closely to hear a gap. OK, so the problem is that after remuxing with ffmpeg, there is a barely audible ... gap ... between the two files, right? 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? Additionally it seems the created files contain neither. And leaving out these id3 options doesn't change the output from lame. So I'm not sure how this is supposed to work. Best regards, Andreas ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Bug#797965: bs1770gain somehow "destroys" gapless playback on (at least) lame encoded MP3s
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 tag, but padded in some other parts of the MP3 header which aren't used. http://gabriel.mp3-tech.org/mp3infotag.html http://wiki.hydrogenaud.io/index.php?title=LAME#VBR_header_and_LAME_tag http://libzplay.sourceforge.net/LAMETAG.html > You've used lame with '--id3v2-utf16 --add-id3v2 --id3v1-only'. > What is this supposed to do? Add id3v1 tags, or id3v2 or both? IIRC the problem was that either bs1770gain but more likely python- rgain (which I had to use in the end, because of the problem with bs1770gain) didn't set any replay gain tags (which *are* in fact ID3 tags) at all, when no ID3 was present at all. These options basically made, that both a ID3v1 and ID3v2 "section" was created (the later with UTF16 encoding), however with no tags. > Additionally it seems the created files contain neither. Hmm... maybe I did in addition set one dummy tag like --tc=' ', and removed that afterwards. > And leaving out these id3 options doesn't change the output > from lame. > > So I'm not sure how this is supposed to work. What exactly now? The stuff with the tags? I guess you can ignore that, since I've just had it in place for, IIRC, python-rgain,... What I would assume that ffmpeg does, is, that it simply drops or somehow mangles up the LAMEtag,... or actually modifies the audio stream so that it doesn't fit to the LAMEtag anymore. Cheers, Chris. smime.p7s Description: S/MIME cryptographic signature ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Bug#797965: bs1770gain somehow "destroys" gapless playback on (at least) lame encoded MP3s
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 adding the first version of it to FFmpeg some time ago but unfortunately not based on my proposal (just copy it) but the way the FFmpeg team wants to have it. Meanwhile it's changed anyway. ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Bug#797965: BS1770GAIN
[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 FFmpeg. This sound like a good argument for reassigning this bug report to ffmpeg. But I suspect the maintainers are going to need a way to reproduce it. Can you provide those details before we pass this bug on to ffmpeg? -- Happy hacking Petter Reinholdtsen ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Bug#797965: BS1770GAIN
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 FFmpeg will have fixed their errors. They are the experts for those myriads of formats and codecs. Please file these errors under FFmpeg. Thanks, Peter ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Bug#797965: BS1770GAIN
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 when played back. So apart from the fact that I wonder why ffmpeg is used here at all (shouldn't just some ID3 tags or that like be written?), it may be an issue in ffmpeg. btw: Using ffmpeg, even in copy mode seems to have other issues as well: ffmpeg version 2.7.2-2+b1 Copyright (c) 2000-2015 the FFmpeg developers built with gcc 5.2.1 (Debian 5.2.1-15) 20150808 configuration: --prefix=/usr --extra-version=2+b1 --build-suffix=-ffmpeg --toolchain=hardened --libdir=/usr/lib/x86_64-linux-gnu --incdir=/usr/include/x86_64-linux-gnu --enable-gpl --enable-shared --disable-stripping --enable-avresample --enable-avisynth --enable-frei0r --enable-gnutls --enable-ladspa --enable-libass --enable-libbluray --enable-libbs2b --enable-libcaca --enable-libcdio --enable-libflite --enable-libfontconfig --enable-libfreetype --enable-libfribidi --enable-libgme --enable-libgsm --enable-libmodplug --enable-libmp3lame --enable-libopenjpeg --enable-openal --enable-libopus --enable-libpulse --enable-librtmp --enable-libschroedinger --enable-libshine --enable-libspeex --enable-libtheora --enable-libtwolame --enable-libvorbis --enable-libvpx --enable-libwavpack --enable-libwebp --enable-libxvid --enable-libzvbi --enable-opengl --enable-x11grab --enable-libdc1394 --enable-libiec61883 --enable-libzmq --enable-libssh --enable-libx264 --enable-libopencv --enable-libx265 WARNING: library configuration mismatch avcodec configuration: --prefix=/usr --extra-version=2+b1 --build-suffix=-ffmpeg --toolchain=hardened --libdir=/usr/lib/x86_64-linux-gnu --incdir=/usr/include/x86_64-linux-gnu --enable-gpl --enable-shared --disable-stripping --enable-avresample --enable-avisynth --enable-frei0r --enable-gnutls --enable-ladspa --enable-libass --enable-libbluray --enable-libbs2b --enable-libcaca --enable-libcdio --enable-libflite --enable-libfontconfig --enable-libfreetype --enable-libfribidi --enable-libgme --enable-libgsm --enable-libmodplug --enable-libmp3lame --enable-libopenjpeg --enable-openal --enable-libopus --enable-libpulse --enable-librtmp --enable-libschroedinger --enable-libshine --enable-libspeex --enable-libtheora --enable-libtwolame --enable-libvorbis --enable-libvpx --enable-libwavpack --enable-libwebp --enable-libxvid --enable-libzvbi --enable-opengl --enable-x11grab --enable-libdc1394 --enable-libiec61883 --enable-libzmq --enable-libssh --enable-libx264 --enable-libopencv --enable-libx265 --enable-version3 --disable-doc --disable-programs --disable-avdevice --disable-avfilter --disable-avformat --disable-avresample --disable-postproc --disable-swscale --enable-libopencore_amrnb --enable-libopencore_amrwb --enable-libvo_aacenc --enable-libvo_amrwbenc libavutil 54. 27.100 / 54. 27.100 libavcodec 56. 41.100 / 56. 41.100 libavformat56. 36.100 / 56. 36.100 libavdevice56. 4.100 / 56. 4.100 libavfilter 5. 16.101 / 5. 16.101 libavresample 2. 1. 0 / 2. 1. 0 libswscale 3. 1.101 / 3. 1.101 libswresample 1. 2.100 / 1. 2.100 libpostproc53. 3.100 / 53. 3.100 [mp3 @ 0x15a8e40] Skipping 0 bytes of junk at 417. Input #0, mp3, from '2.mp3': Duration: 00:10:45.09, start: 0.025057, bitrate: 166 kb/s Stream #0:0: Audio: mp3, 44100 Hz, stereo, s16p, 166 kb/s Metadata: encoder : LAME3.99r Output #0, mp3, to 'b.mp3': Metadata: TSSE: Lavf56.36.100 Stream #0:0: Audio: mp3, 44100 Hz, stereo, 166 kb/s Metadata: encoder : LAME3.99r Stream mapping: Stream #0:0 -> #0:0 (copy) Press [q] to stop, [?] for help [mp3 @ 0x15abba0] Audio packet of size 128 (starting with 54414700...) is invalid, writing it anyway. size= 13141kB time=00:10:45.09 bitrate= 166.9kbits/s video:0kB audio:13140kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: 0.003872% As one can see above here, there's an error that ffmpeg thinks something would be invalid. It seems to still write it here, but I'd guess that the copy mode is still like a full parsing and freshly rewriting. Sounds like an invitation for all kinds of things going wrong :-( @Peter: Why exactly do you need to use ffmpeg for writing? Shouldn't it be enough to write some tags? Cheers, Chris. smime.p7s Description: S/MIME cryptographic signature ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Bug#797965: bs1770gain somehow "destroys" gapless playback on (at least) lame encoded MP3s
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-id3v2 --id3v1-only 1.wav lame --verbose -q 0 -v -V 3 --noreplaygain --id3v2-utf16 --add-id3v2 --id3v1-only 2.wav than the resulting 1.mp3 and 2.mp3 play flawlessly gapless with e.g. mpv or on the ipod (mplayer or totem don't seem to support gapless playback at all). But once after I did e.g.: $ bs1770gain -ismrpt --replaygain -o r/ music/ or: $ bs1770gain -ismrpt -o e/ music/ (with music containing the two MP3s) then the resulting MP3s in e/ rspectively r/ no longer play gaplessly, neither with mpv nor on the ipod. When I do however: $ collectiongain --regain music/ using the ReplayGain implementation from the python-rgain package, then the resulting files still play perfectly gapless in mpv/ipod. Cheers, Chris. PS: I've already notified upstream about this in a private mail. ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
