Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Error] Error encoding: Invalid argument! - Toxic combination of Opus and offsets #99

Open
finackninja opened this issue Dec 24, 2024 · 0 comments

Comments

@finackninja
Copy link

I am experiencing a terminating error using cyanrip on some discs when I specify a nonzero offset and Opus output.

Description of issue

Ripping fails on the first track with a segmentation fault when ripping some discs that have a nonzero offset (e.g., -25852, +6), but not all (e.g., -74), when specifying Opus as an output format.

Suspected cause

Invalid parameters are sometimes being sent to the Opus encoder (ffmpeg?) when there is a nonzero offset.

Known Workarounds

  • Rip with zero offset (-s 0).
  • Do not output to Opus.

System details:

Operating System: Ubuntu 24.04.1 LTS
Kernel Version: 6.8.0-51-generic
cyanrip version: cyanrip 0.9.0 (release)*
ffmpeg vesrion: ffmpeg version 6.1.1-3ubuntu5

Both cyanrip and ffmpeg (and any missing dependencies) were installed via Ubuntu's repositories using apt.

* The installed version of cyanrip reported by itself (i.e., cyanrip -V) is 0.9.0; however, based on cyanrip's behavior on my system and the changelog, it seems I actually have version 0.9.2. cyanrip on my system generates CUE sheets (added in 0.9.2) but does not allow me to specify the image size for album art (added in 0.9.3).

Steps to reproduce

  1. Insert a known troublesome disc.
  2. Run cyanrip -f.
  3. Observe offset is -25852.
  4. Run cyanrip -o flac,opus -b 192 -U -G -s -25852.

Example output

cyanrip

username@computername:~/Documents/Music/rip$ cyanrip -o flac,opus -b 192 -U -G -s -25852
Checking /dev/cdrom for cdrom...
		CDROM sensed: TSSTcorp CDDVDW SE-S084F  TS00 SCSI CD-ROM


Opening drive...
Found MusicBrainz release: Live at Red Rocks 8.15.95 - Dave Matthews Band
cyanrip 0.9.0 (release)
System device:  /dev/cdrom
Device model:   TSSTcorp CDDVDW SE-S084F  TS00 SCSI CD-ROM
Offset:         -25852 samples
Underread:      -44 frames
Underread mode: fill with silence in lead-in/lead-out
Speed:          default (unchangeable)
C2 errors:      supported by drive
Paranoia level: max
Frame retries:  10
HDCD decoding:  disabled
Album Art:      none
Outputs:        flac, opus
Disc number:    2
Total discs:    2
Disc tracks:    8
Tracks to rip:  all
DiscID:         R83c6itV5xzE8SMEUf9vyX4zLPY-
Release ID:     f5b1582c-65aa-4df5-ab2f-9d8ad2953be3
CDDB ID:        6C0DB008
Disc MCN:       0000000000000
Album:          Live at Red Rocks 8.15.95
Album artist:   Dave Matthews Band
AccurateRip:    found
Total time:     00:58:24.348

Gaps:
    None signalled

Tracks:
Error encoding: Invalid argument!
Error in decoding/sending frame: Invalid argument
Album Loudness Summary:

  Integrated loudness:
    I:         -70.0 LUFS
    Threshold:   0.0 LUFS

  Loudness range:
    LRA:         0.0 LU
    Threshold:   0.0 LUFS
    LRA low:     0.0 LUFS
    LRA high:    0.0 LUFS

  True peak:
    Peak:       -inf dBFS

Segmentation fault (core dumped)
username@computername:~/Documents/Music/rip$

journalctl

Dec 24 11:35:03 computername kernel: cyanrip[80728]: segfault at 48 ip 00005c1bac1e6fb3 sp 00007fffa26a2a90 error 4 in cyanrip[5c1bac1e1000+12000] likely on CPU 3 (core 1, socket 0)
Dec 24 11:35:03 computername kernel: Code: 0f 8e 51 fc ff ff 4c 69 eb 78 01 00 00 45 31 e4 4d 01 fd eb 04 49 83 c4 01 45 39 a7 98 04 00 00 7e 20 4f 8b b4 e5 b8 05 00 00 <41> 83 7e 48 00 74 e4 49 8d 7e 50 e8 ed b7 ff ff 31 f6 41 89 76 48

Example disc:

Artist: Dave Matthews Band
Album: Live at Red Rocks 8.15.95
MusicBrainz Release ID: f5b1582c-65aa-4df5-ab2f-9d8ad2953be3
Disc: 2

Details

This issue typically will occur shortly after the disc spins up on the first track of the disc and end ripping. It does not show any progress, as if no ripping started. The result on disk is two directories ("Live at Red Rocks 8.15.95 [FLAC]" and "Live at Red Rocks 8.15.95 [OPUS]" in this case), each with a single .flac or .opus file named for the first track (e.g., "2.1 - Tripping Billies.flac") as well as a .cue and .log file named after the album and disc number. All resulting files are 0 b in size.

If I do multiple rips to compare checksums using the -Z switch, it will spin the disc, rip the tracks for the first iterations, generate checksums (which almost always match), and then on run it will report the same errors as if I didn't specify -Z and exit.

If I change the offset to 0 (i.e., run cyanrip -o flac,opus -b 192 -U -G -s 0), it will rip the disc and create output .flac and .opus files for each track successfully; however, it will report all of the results as bad rips relative to AccurateRip (all versions). The files sound fine to my ears.

I also tried doing additional testing by ripping with only FLAC and separately with only Opus output. If I only output FLAC (e.g., cyanrip -o flac -b 192 -U -G -s -25852), it works fine; however, if I only output Opus (e.g., cyanrip -o opus -b 192 -U -G -s -25852), I have the troublesome results.

cyanrip also reports a +6 offset for discs with my drive fairly frequently. I've noticed I always have this problem with +6 offset as well and so I always use -s 0 if I test and see +6 offset. The problem is not universal. For some other discs with different offsets, specifying the offset for the rip session works fine even when specifying Opus as an output format and results in accruate rips relative to AccurateRip.

I believe that something is being passed to the Opus encoder (ffmpeg?) in some cases with a nonzero offset that it doesn't like.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant