scrub corrupts FLACs

[translit]

Problem

FLACs get corrupted after scrubing:

$ beet bad chanson
/music/Artist/Album/01 Chanson.flac: checker exited with status 1
  01 Chanson.flac: *** Got error code 0:FLAC__STREAM_DECODER_ERROR_STATUS_LOST_SYNC
  01 Chanson.flac: ERROR while decoding data
                                                     state = FLAC__STREAM_DECODER_ABORTED

Setup

• OS: macOS High Sierra v. 10.13.1
• Python version: 3.6.3
• beets version: 1.4.5
• Turning off plugins made problem go away (yes/no): yes

My configuration (output of beet config) is:

lyrics:
    bing_lang_from: []
    auto: yes
    google_API_key: REDACTED
    fallback: ''
    bing_client_secret: REDACTED
    bing_lang_to:
    google_engine_ID: REDACTED
    genius_api_key: REDACTED
    force: no
    sources: [google, lyricwiki, musixmatch]
directory: /music
library: ~/.config/beets/library.db

plugins:
- badfiles
- chroma
- convert
- duplicates
- embedart
- fetchart
- info
- lastgenre
- lyrics
- mbsync
- missing
- random
- replaygain
- scrub
- zero

import:
    move: no
    write: yes
    timid: yes
    verbose: yes
acoustid:
    apikey: REDACTED
badfiles:
    commands:
        flac: flac --test --warnings-as-errors --silent
convert:
    dest: ~/Music/Converted
    copy_album_art: yes
    never_convert_lossy_files: yes
    pretend: no
    threads: 4
    format: mp3
    formats:
        aac:
            command: ffmpeg -i $source -y -vn -acodec aac -aq 1 $dest
            extension: m4a
        alac:
            command: ffmpeg -i $source -y -vn -acodec alac $dest
            extension: m4a
        flac: ffmpeg -i $source -y -vn -acodec flac $dest
        mp3: ffmpeg -i $source -y -vn -aq 2 $dest
        opus: ffmpeg -i $source -y -vn -acodec libopus -ab 96k $dest
        ogg: ffmpeg -i $source -y -vn -acodec libvorbis -aq 3 $dest
        wma: ffmpeg -i $source -y -vn -acodec wmav2 -vn $dest
    max_bitrate: 500
    auto: no
    tmpdir:
    quiet: no
    embed: yes

    paths: {}
    album_art_maxwidth: 0
duplicates:
    keys: artist title
    album: no
    checksum: ''
    copy: ''
    count: no
    delete: no
    format: ''
    full: no
    merge: no
    move: ''
    path: no
    tiebreak: {}
    strict: no
    tag: ''
embedart:
    auto: no
    maxwidth: 0
    compare_threshold: 0
    ifempty: no
    remove_art_file: no
fetchart:
    auto: no
    cautious: no
    cover_names: cover front art album folder
    minwidth: 600
    maxwidth: 1000
    enforce_ratio: 20%
    sources: filesystem fanarttv coverart
    google_key: REDACTED
    fanarttv_key: REDACTED
    google_engine: REDACTED
    store_source: no
lastgenre:
    auto: yes
    canonical: yes
    count: 1
    force: yes
    source: album
    whitelist: yes
    min_weight: 10
    fallback:
    separator: ', '
    prefer_specific: no
replaygain:
    auto: yes
    backend: gstreamer
    overwrite: yes
    targetlevel: 89
    r128: [Opus]
scrub:
    auto: no
zero:
    auto: yes
    fields: comments
    update_database: yes
    keep_fields: []
chroma:
    auto: yes
missing:
    count: no
    total: no
    album: no

[sampsyo]

Hmm; I can't reproduce this with a FLAC file I have on hand:

$ beet scrub 'the artist'
scrub: scrubbing: /Users/asampson/code/beets/_etc/testlib/Non-Album/the artist/full.flac
$ beet bad -v 'the artist'
/Users/asampson/code/beets/_etc/testlib/Non-Album/the artist/full.flac: ok
$

Do you have a test case that would let us reproduce the problem?

[translit]

I wonder how best let you grab the files. Do you have Usenet? Here's the NZB. album.txt

[sampsyo]

No, sorry—any chance you can craft a small, truncated file that exhibits the problem?

[mineo]

This is a bit of a wild guess, but is there any chance that gstreamer touched the corrupted files? We have people with the same error messages from flac --test over at Picard: https://tickets.metabrainz.org/browse/PICARD-1088.

[translit]

Absolutely! I also have this in my config:

replaygain:
    auto: yes
    backend: gstreamer
    overwrite: yes

Really annoying to worry constantly about corruption. It doesn't happen to all FLACs though, only to some. I keep backups now.

[tummychow]

If anyone still has repros of this issue, what does metaflac --list look like? The gstreamer bug (https://bugzilla.gnome.org/show_bug.cgi?id=727802#c28 and https://bugzilla.gnome.org/show_bug.cgi?id=785558) seems to suggest metadata being corrupted. In my case, the metadata is fine (confirmed by metaflac), and I still get the LOST_SYNC error even after metaflac --remove-all --dont-use-padding (discarding all metadata on the file). I have to fully reencode the file to fix the error, which suggests to me that it's not the aforementioned gstreamer bug. (might still be a gstreamer bug, but it's not that one)

e: hm, never mind me, the issue seems to be with the actual audio track in the version of the file that I have... reimporting a new non-errored copy of the file creates no issues, so beets is probably not involved

[translit]

I'm sorry that I can't contribute to the investigation, but it's great to see you looking into that issue. It killed half of my library back in the day.

[stale[bot]]

Is this still relevant? If so, what is blocking it? Is there anything you can do to help move it forward?

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.