Using custom fields as aunique keys

Help
1

I often have multiple versions of the same album in different resolutions: 16/44 and 24/96, for example. I would beets to treat the same album in different resolutions as a different album and thus not add the disambiguators at the end of the album name if this occurs.

My thought was to add two custom fields to the keys field under aunique: album_bitdepth and album_samplerate so that the same album at different resolutions is not treated as a duplicate.

aunique:
    keys: original_year albumartist album album_bitdepth album_samplerate
    disambiguators: albumtype label catalognum albumdisambig releasegroupdisambig
    bracket: '{}'

album_fields:  
      album_bitdepth: |
       total = 0
       for item in items:
           total += item.bitdepth
       return round(total / len(items))
    album_samplerate: |
       total = 0
       for item in items:
           total += item.samplerate
       return round(total / len(items) / 1000)

However setting the config up this way and performing beet move does not produce the correct output and shows no_such_column as part of the output filename. For example:

/Volumes/Data/Music/Albums/T/Tool/1996 - Tool - Ænima [CD]/15 - Third Eye.flac 
  -> /Volumes/Data/Music/Albums/T/Tool/1996 - Tool - Ænima [CD]_no such column_ album_bitdepth_/15 - Third Eye.flac

Any suggestions on making this work? Thanks!

2

Makes sense to support! We don’t currently do it because queries on flexible attributes work a bit differently, and this line:

…would need to behave differently depending on whether it’s a fixed (built-in) field or a flexible/user-defined attribute. Would you mind opening a feature request ticket?

It’s worth noting that doing this sort of thing will inevitably make things a bit slower than the standard operation with built-in fields.

3

Filed a feature request. Thanks for considering.

1 Like