Bug#797965: bs1770gain somehow "destroys" gapless playback on (at least) lame encoded MP3s
Controle: retitle -1 ffmpeg destroys gapless playback on (at least) MP3s
Bug#797965: bs1770gain somehow "destroys" gapless playback on (at least) lame encoded MP3s
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
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 surprise as files are decoded to flac (which is per se gapless), but this is probably not what most people want. Seems a bit as if something is going wrong when the mp3 stream is remuxed or stored again. With the unfortunate removal of python-rgain, bs1770gain seems to be the only remaining replaygain tool in Debian... so it would be really nice if ffmpeg could be made no breaking the output files :-) Cheers, Chris.
Bug#797965: bs1770gain somehow "destroys" gapless playback on (at least) lame encoded MP3s
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/ticket/7828#comment:2 https://github.com/mpv-player/mpv/issues/2284#issuecomment-479667296 Long story short: In mpv MP3/Opus play gapless quite fine. In ffmpeg, it works at least with the version from git (but not with the one in Debian); reasons seems to be an issue in the ffmpeg(1) program itself which was recently fixed... while mpv used the libs already correctly. >From that I'd have expected that bs1770gain also works now and files that have been processed by it still play back gaplessly, however it does not. 1) First pair of test files >From the test-files from the two bug reports above I used: 02.split-track01.mp3 02.split-track02.mp3 and 03.split-track01.opus 03.split-track02.opus each of them in a directory, which I then processed (each dir) with: bs1770gain dir -t -o outdir Playing these with: mpv 02.split-track01.mp3 02.split-track02.mp3 respectively mpv 03.split-track01.opus 03.split-track02.opus works without any gap/distortion. Fine so far, but now... 2) Second pair of test files I do have another pair of sample file from an audio CD. Encoded them exactly as described in the ffmpeg/mpv tickets with lame respectively opusenc. Processed them as above with bs1770gain (the Debian version from sid, with the ffmpeg version from sid). With the (bs1770gain processed) MP3 files, there is a distortion/corruption at the the intersection, which I can clearly hear. However... the (bs1770gain processed) Opus files are fine!!! (wtf?) It can also be seen in the waveform (see attached images): For that I decoded the files with lame --decode respectively opusdec (not with ffmpeg this time), joined each pair together with sox and displayed them in sonic-visualizer with: top: the sox concatenation of the original two WAV sample files middle: the joined WAVs decoded from the MP3 respectively Opus bottom: just the WAV of first track from MP3 respectively Opus, serving just as reference as to where the intersection is Any idea why the MP3 is still mangled up? It apparently seems to depend on the input file... so maybe it's just luck, that the Opus worked here. Thanks, Chris. btw: As for the sample files, I wouldn't want to upload them publicly since these are from some copyrighted Audio CD,... but I can make them privately available to some developers if this is desired.
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
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-maintain...@lists.alioth.debian.org > http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers -- Sebastian Ramacher signature.asc Description: PGP signature
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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.
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.
