Replaygain with ffmpeg throws error when filename has special characters in Windows

[gregsanz182]

Problem

Running this command in verbose (-vv) mode with ffmpeg:

$ beet -v --config .\songs.yaml replaygain -f queens of the stone age era vulgaris

Led to this problem:

replaygain: executing ffmpeg -nostats -hide_banner -i C:\Users\sanch\Music\Songs\Queens of the Stone Age\[2007] Era Vulgaris\02- Sick, Sick, Sick.m4a -map a:0 -filter ebur128=peak=true -f null -
replaygain: executing ffmpeg -nostats -hide_banner -i C:\Users\sanch\Music\Songs\Queens of the Stone Age\[2007] Era Vulgaris\08- 3’s & 7’s.mp3 -map a:0 -filter ebur128=peak=true -f null -
replaygain: ffmpeg exited with status 4294967294

While checking the actual command call, I noticed the path to the files is sent as binary, like this:

C:\\Users\\sanch\\Music\\Songs\\Queens of the Stone Age\\[2007] Era Vulgaris\\08- 3\xc3\xa2\xe2\x82\xac\xe2\x84\xa2s & 7\xc3\xa2\xe2\x82\xac\xe2\x84\xa2s.mp3

I tried converting the path to string using the syspath util, and it seems that did the trick

I don't know wether to make a pull request, as this is my first time looking at this source code, and I don't know if this is the right solution

Setup

• OS: Windows 11
• Python version: 3.9.13
• beets version: 1.6.0
• Turning off plugins made problem go away (yes/no): no

My configuration (output of beet config) is:

library: ~/beets/songs.db
directory: ~/Music/Songs
art_filename: folder
original_date: yes
per_disc_numbering: yes

import:
  copy: yes
  timid: true

plugins: chroma inline convert lastgenre fetchart embedart albumtypes mbsync replaygain

convert:
  auto: yes
  quiet: true
  never_convert_lossy_files: yes
  format: aac
  formats:
    aac:
      command: qaac $source --cvbr 320 -o $dest
      extension: m4a

lastgenre:
  auto: yes
  separator: ';'
  source: album
  title_case: yes
  count: 5

fetchart:
  auto: yes
  cover_names: folder
  sources: filesystem

embedart:
  auto: yes
  ifempty: no

albumtypes:
  types:
    - ep: 'EP'
    - single: 'Single'
    - live: 'Live'
    - compilation: 'Comp'
    - demo: 'Demo'
    - remix: 'Remix'

item_fields:
  is_multidisc: disctotal > 1
  disc_name: "u'Disc %02i - %s' % (disc, disctitle) if disctitle else u'Disc %02i' % (disc)"

paths:
  default: '$albumartist/[$year] $album%aunique{}/%if{$is_multidisc,$disc_name/}$track- $title'

replaygain:
  auto: true
  backend: ffmpeg

[wisp3rwind]

Not sure what's going on here, but one quick remark: This decoding from the beets-internal bytes-representation to str should be handled by beets.util.command_output in the call to beets.convert_command_args. So, the extra syspath shouldn't be required really.

So, in principle, yes please open a pull request. However, in this case we should try to better understand where the issue really is.

While checking the actual command call, I noticed the path to the files is sent as binary, like this:

How did you check this? Is this really the command that is ultimately provided to the subprocess call?

You might try to add some logging to beets.util.command_output (just before the Popen) and compare what exactly changes with and without the extra syspath.