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.

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
  libavformat    56. 36.100 / 56. 36.100
  libavdevice    56.  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
  libpostproc    53.  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.

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

[Peter Belkner]

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?

ffmpeg -i <in.mp3> -acodec copy -y <out.mp3>

erases gapless.

Regards

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.

Hi,

Can you provide a sample for reproducing this problem?

Best regards,
Andreas

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.

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.

Hi Peter,

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

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

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

Any

    ffmpeg -i <in.mp3> -acodec copy -y <out.mp3>

should do it.

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.

Wait a few minutes...

Hi,

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

Yes
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
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.
Hmm... maybe I did in addition set one dummy tag like --tc=' ', and
removed that afterwards.
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.

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.

Hi,

Thanks for this clarification. I was indeed confused by the ID3 tags
mentioned in the initial report.

Indeed, FFmpeg parses the XING/LAME header when demuxing and then
writes a new one when muxing.

Oh cool! What a coincidence!

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

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

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.

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

[Mails to nnnnnn@bugs.debian.org do not reach the submitter. Explicitly CC-ing
Christoph]

Hi Cris,

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

tag 797965 pending
thanks

Hello,

Bug #797965 reported by you has been fixed in the Git repository. You can
see the changelog below, and you can check the diff of the fix at:

http://git.debian.org/?p=pkg-multimedia/ffmpeg.git;a=commitdiff;h=191ec5c

    Finalize changelog

diff --git a/debian/changelog b/debian/changelog
index 88975bb..8d57546 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,31 @@
+ffmpeg (7:3.1.5-1) unstable; urgency=medium
+
+  * Import new upstream bugfix release 3.1.5.
+  * Use nasm instead of yasm.
+    - Unlike yasm it is actively maintained upstream.
+    - And it doesn't embed the full build path as DW_AT_comp_dir.
+      (This should make ffmpeg fully reproducible.)
+  * Drop patches, fixed differently upstream:
+    - disable-opj-static.patch
+    - libopenjpegenc-recreate-image-data-buffer.patch
+  * Add patches from upstream:
+     - doc-fix-spelling-errors.patch (Closes: #839542)
+     - faq-use-relative-links-to-own-documentation.patch (Closes: #841501)
+     - ffmpeg_opt-Suggest-to-use-file-.-if-a-protocol-was-not-fo.patch
+       (Closes: #785690)
+     - lavf-mp3enc-write-encoder-delay-padding-upon-closing.patch
+       (Closes: #797965)
+     - tests-checkasm-pixblockdsp-Test-8-byte-aligned-positions.patch
+       (LP: #1612058)
+  * Use debhelper compat 10.
+     - Parallel building is now the default.
+  * Revert: Enable all hardening options except pie.
+     - It doesn't have any effect, anyway.
+     - PIE is now the default.
+  * Adapt lintian overrides to PIE by default.
+
+ -- Andreas Cadhalpun <Andreas.Cadhalpun@googlemail.com>  Sat, 22 Oct 2016 22:33:02 +0200
+
 ffmpeg (7:3.1.4-1) unstable; urgency=medium

   [ Ondřej Nový ]

We believe that the bug you reported is fixed in the latest version of
ffmpeg, which is due to be installed in the Debian FTP archive.

A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 797965@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Andreas Cadhalpun <Andreas.Cadhalpun@googlemail.com> (supplier of updated ffmpeg package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmaster@ftp-master.debian.org)
Format: 1.8
Date: Sat, 22 Oct 2016 22:33:02 +0200
Source: ffmpeg
Binary: ffmpeg ffmpeg-doc libavcodec57 libavcodec-extra57 libavcodec-extra libavcodec-dev libavdevice57 libavdevice-dev libavfilter6 libavfilter-extra6 libavfilter-extra libavfilter-dev libavformat57 libavformat-dev libavresample3 libavresample-dev libavutil55 libavutil-dev libpostproc54 libpostproc-dev libswresample2 libswresample-dev libswscale4 libswscale-dev libav-tools
Architecture: source
Version: 7:3.1.5-1
Distribution: unstable
Urgency: medium
Maintainer: Debian Multimedia Maintainers <pkg-multimedia-maintainers@lists.alioth.debian.org>
Changed-By: Andreas Cadhalpun <Andreas.Cadhalpun@googlemail.com>
Description:
 ffmpeg     - Tools for transcoding, streaming and playing of multimedia files
 ffmpeg-doc - Documentation of the FFmpeg multimedia framework
 libav-tools - Compatibility links for libav-tools (transitional package)
 libavcodec-dev - FFmpeg library with de/encoders for audio/video codecs - developm
 libavcodec-extra - FFmpeg library with extra codecs (metapackage)
 libavcodec-extra57 - FFmpeg library with additional de/encoders for audio/video codecs
 libavcodec57 - FFmpeg library with de/encoders for audio/video codecs - runtime
 libavdevice-dev - FFmpeg library for handling input and output devices - developmen
 libavdevice57 - FFmpeg library for handling input and output devices - runtime fi
 libavfilter-dev - FFmpeg library containing media filters - development files
 libavfilter-extra - FFmpeg library with extra filters (metapackage)
 libavfilter-extra6 - FFmpeg library with extra media filters - runtime files
 libavfilter6 - FFmpeg library containing media filters - runtime files
 libavformat-dev - FFmpeg library with (de)muxers for multimedia containers - develo
 libavformat57 - FFmpeg library with (de)muxers for multimedia containers - runtim
 libavresample-dev - FFmpeg compatibility library for resampling - development files
 libavresample3 - FFmpeg compatibility library for resampling - runtime files
 libavutil-dev - FFmpeg library with functions for simplifying programming - devel
 libavutil55 - FFmpeg library with functions for simplifying programming - runti
 libpostproc-dev - FFmpeg library for post processing - development files
 libpostproc54 - FFmpeg library for post processing - runtime files
 libswresample-dev - FFmpeg library for audio resampling, rematrixing etc. - developme
 libswresample2 - FFmpeg library for audio resampling, rematrixing etc. - runtime f
 libswscale-dev - FFmpeg library for image scaling and various conversions - develo
 libswscale4 - FFmpeg library for image scaling and various conversions - runtim
Closes: 785690 797965 839542 841501
Changes:
 ffmpeg (7:3.1.5-1) unstable; urgency=medium
 .
   * Import new upstream bugfix release 3.1.5.
   * Use nasm instead of yasm.
     - Unlike yasm it is actively maintained upstream.
     - And it doesn't embed the full build path as DW_AT_comp_dir.
       (This should make ffmpeg fully reproducible.)
   * Drop patches, fixed differently upstream:
     - disable-opj-static.patch
     - libopenjpegenc-recreate-image-data-buffer.patch
   * Add patches from upstream:
      - doc-fix-spelling-errors.patch (Closes: #839542)
      - faq-use-relative-links-to-own-documentation.patch (Closes: #841501)
      - ffmpeg_opt-Suggest-to-use-file-.-if-a-protocol-was-not-fo.patch
        (Closes: #785690)
      - lavf-mp3enc-write-encoder-delay-padding-upon-closing.patch
        (Closes: #797965)
      - tests-checkasm-pixblockdsp-Test-8-byte-aligned-positions.patch
        (LP: #1612058)
   * Use debhelper compat 10.
      - Parallel building is now the default.
   * Revert: Enable all hardening options except pie.
      - It doesn't have any effect, anyway.
      - PIE is now the default.
   * Adapt lintian overrides to PIE by default.
Checksums-Sha1:
 716ef7e4cea53629923178c002490be8ad8c11cb 4734 ffmpeg_3.1.5-1.dsc
 dc3e61f41ef9c58ec79558cf390cf9e026dde807 7813540 ffmpeg_3.1.5.orig.tar.xz
 ecb71479772e47acb22adfb2e59cb8a62c73a457 42684 ffmpeg_3.1.5-1.debian.tar.xz
Checksums-Sha256:
 5f0cfb600cc1dce2185edec1d49f2bb8ffbad62b3d45af2bb69d40f320acbeb7 4734 ffmpeg_3.1.5-1.dsc
 49cc3105f7891c5637f8fabb1b75ebb19c9b5123b311a3ccc6182aa35d58b89a 7813540 ffmpeg_3.1.5.orig.tar.xz
 c1a559037a8962dfa47fe20ecbb11d8ec4c7194ff1db3e01bcd714a956b94a89 42684 ffmpeg_3.1.5-1.debian.tar.xz
Files:
 5cc4689e765a08cf33679e83ee104433 4734 video optional ffmpeg_3.1.5-1.dsc
 a09f7730ceeb665c6f7da0b884dd00f9 7813540 video optional ffmpeg_3.1.5.orig.tar.xz
 c27d921f80d7a59698aafee420a53687 42684 video optional ffmpeg_3.1.5-1.debian.tar.xz
iQIcBAEBCAAGBQJYDMNKAAoJEPZk0la0aRp9tyUP/ixqQKrUs9trXlCiIHFdKUp0
AOv1QWgQPPa/ewr1e9lZvJOVkcN2kCgPYce+TGg39doPQFOiyfojLg+y7wihgPQx
HueOjgejLt4tq5y5wxoWkKkfkklibfD3szustcKYLzJDTG5dnkR96EC/EjZRkgFR
ZzgniQ5qH0+hI9T/HexdTBq7MiBmC8MdWOj4SXx1XTxQ+f12YmESTL3bAyAQFGBI
SnhSf35kCHoYU6b3gNE3K8+wBzmP57xe/V21xFELrEbgdtnl0kX1zk8+OBUcHxZA
w5/A0x5+qNdqi2eA58sVClSW1O/GM/uehVhW18qXhWXxRPKZQl4x88yL54Aa19Y5
WSYZ71xSHFrcWuH0EMtkHq2WmtW6Rl/uM8WPjCCbXvGtDbcosEbuH3Vu3PBZHz3V
gdadWKWZB/dKXPdcnV3bTGW+436jI5hbrdqwhv1JxUqBWNlmgBaImT6tg4IyTllk
w0rscZl77q5mQNBdUU5k1DhcA90xYPqgAgxtgvh64jUdmgBCOB+k5MX2aZMp8++q
EUmKahmuVeBR00btJn+s1xzKWbyvxHe8dA6HO0TEYh+6/nuT37Z2kLvGfBpRWTY6
iTLATZLwXnxnAZdbNnKg5FDSDoRVn5RcWCQYgtwCrEVR9ntlAFHiZVjiWlCg57UL
V6VO0DAtFPW33tk3eCR5
=HwyM
-----END PGP SIGNATURE-----

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.

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.

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.

Hey there.

I just retried that again, both:
- with bs1770gain and
- with plain ffmpeg -i in.mp3 -acodec copy -y out.mp3


and it seems that this must have been fixed at some point in ffmpeg.

Gapless playback is at least preserved for MP3 and Opus (didn't check
other formats).

This requires of course the use of bs1770gain’s --codec and --suffix
options, otherwise stuff would be converted to FLAC in an MKV
container.

Also, when using these options to get the same codec/container, ffmpeg
seems to really copy the encoded audio stream.

The files may still differ (even with plain ffmpeg copy) because ffmpeg
seems to add it's own meta data for some reason.



Anyway, this should be fixed, thus closing.

Thanks,
Chris.

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, on some files at least, when these are just copied.

Cheers,
Chris.