Hi all,
with Picard and the Tango.info plugin I often get the date of recording of the old tango shellacs. Picard stores it in DATE. I am using flac files. The values are stored in the flac vorbis comments. I controlled it with VLC. But they don’t show up after a “beet up”.
beet up always worked when I change a tag in EasyTag but with Picard it does not work.
How can I update the beet database?
Can you clarify what’s going on with an example? For instance, maybe you can show the output of beet info or another tool that lists the data you want to pick up, and then show a beet ls -f '...format...' command that you wish produced the same value.
Picard found the recording date. Look at the date 1942-01-08
After saving the file, the metadata is in the file.
This is what VLC shows me:
But beet does not get the changes after a beet up.
beet info Troilo Malena
/home/juh/Musik/Aníbal Troilo/Tinta Roja/02 Malena (canta Fiorentino).flac
acoustid_fingerprint:
acoustid_id:
album: Tinta Roja
albumartist: Aníbal Troilo
albumartist_credit:
albumartist_sort:
albumdisambig:
albumstatus:
albumtype:
arranger:
art: False
artist: Francisco Fiorentino
artist_credit:
artist_sort:
asin:
bitdepth: 16
bitrate: 328478
bpm: 0
catalognum:
channels: 2
comments: Canta Francisco Fiorentino
comp: False
composer: Lucio Demare – Homero Manzi
country:
date: 1941-01-01
disc: 126
disctitle:
disctotal: 0
encoder:
format: FLAC
genre: Tango
genres: Tango
grouping:
label:
language:
length: 178.85333333333332
lyricist: Homero Manzi
lyrics:
mb_albumartistid:
mb_albumid:
mb_artistid:
mb_releasegroupid:
mb_trackid:
media:
original_year: 0
samplerate: 44100
script:
title: Malena (canta Fiorentino)
track: 2
tracktotal: 0
year: 1941
Hmm; that’s interesting! We should be reading the date field. Two questions:
beet -v update '/home/juh/Musik/Aníbal Troilo/Tinta Roja/02 Malena (canta Fiorentino).flac' look like?Hi Adrian,
things become clearer.
First Question:
Yes, it has a year tag with 1941.
Second Question:
I was blind and didn’t saw that I messed up my library paths.
beet info shows the wrong path:
~/Musik instead of ~/beet.
I only saw this now.
My config is ok AFAICS:
$ beet config
directory: ~/beet
convert:
never_convert_lossy_files: yes
copy_album_art: yes
dest: ~/ogg
format: ogg
command: oggenc -q 6 $source -o $dest
auto: no
pretend: no
embed: yes
threads: 8
album_art_maxwidth: 0
quiet: no
paths: {}
formats:
mp3: ffmpeg -i $source -y -vn -aq 2 $dest
aac:
extension: m4a
command: ffmpeg -i $source -y -vn -acodec libfaac -aq 100 $dest
flac: ffmpeg -i $source -y -vn -acodec flac $dest
alac:
extension: m4a
command: ffmpeg -i $source -y -vn -acodec alac $dest
wma: ffmpeg -i $source -y -vn -acodec wmav2 -vn $dest
ogg: ffmpeg -i $source -y -vn -acodec libvorbis -aq 3 $dest
opus: ffmpeg -i $source -y -vn -acodec libopus -ab 96k $dest
max_bitrate: 500
tmpdir:
plugins: play edit convert export mbcollection mbsubmit info
paths:
albumtype:audiobook: Audiobooks/$album/$track $title
library: ~/beetdata/musiclibrary.db
play:
command: vlc
warning_threshold: 100
use_folders: no
raw: no
relative_to:
import:
incremental: yes
languages: de
export:
default_format: json
json:
formatting:
indent: 4
ensure_ascii: no
separators: [',', ': ']
sort_keys: yes
edit:
itemfields: track title artist album
albumfields: album albumartist
ignore_fields: id path
To answer the second question:
(py3) juh@sokrates:~$ beet -v update /home/juh/Musik/Aníbal\ Troilo/Tinta\ Roja/02\ Malena\ \(canta\ Fiorentino\).flac
user configuration: /home/juh/.config/beets/config.yaml
data directory: /home/juh/.config/beets
plugin paths:
Sending event: pluginload
library database: /home/juh/beetdata/musiclibrary.db
library directory: /home/juh/beet
Sending event: library_opened
skipping /home/juh/Musik/Aníbal Troilo/Tinta Roja/02 Malena (canta Fiorentino).flac because mtime is up to date (1492446577.0)
Sending event: cli_exit
Eventually, I copied the file to the Musik-folder, because this is the location for my dj files. I did this with beet move -c -d.
I guess that beet now thinks the file has to be in this folder. My understanding was that it only copied the file and recorded this in the database as a convert or export command. But I fear that beet now treats the copied file as the canonical file of its library.
This behaviour seems consistent to me if I had moved a file into another folder. But after a copy command I would think that beet signals to me that there is a duplicate in the library and ask which one it should treat as the canonical file defaulting to the file in the configured library folder.
So what is the best way to skip all files in ~/Musik and update the database from the files in ~/beet which were altered by Picard.
Thanks a lot for your help.
juh
Hmm… if you have some items in your library that you don’t want there, beet rm is what you want; and if you have a directory of files you want in your library, you can import them. So perhaps you just need to remove old files and add the new ones?
I just try beet -AC to sort this out.
And I removed the unwanted files with
beet remove -f path::^/home/juh/Musik
Now all is consolidated.
In the future I might split the path up again, so that I can easily use certain files with my dj software in a special path. But for now I will leave everything under ~/beet/.
But it still does not work as expected:
(py3) juh@sokrates:~$ beet info "Y la perdi"
/home/juh/beet/Aníbal Troilo/Romance de barrio/13 Y La Perdi.flac
album: Romance de barrio - 1947-1948
albumartist: Aníbal Troilo
albumartist_sort: Troilo, Aníbal
art: False
artist: Floreal Ruiz
artist_sort: Troilo, Aníbal feat. Ruiz, Floreal
asin: B0002U87KS
bitdepth: 16
bitrate: 375935
catalognum: 82876633402
channels: 2
comments: Canta Floreal Ruiz
composer: Antonio Rodio – José Maria Contursi
country: AR
date: 1947-10-07
day: 7
disc: 135
disctotal: 1
format: FLAC
genre: Tango
genres: Tango
label: BMG Argentina
length: 210.74666666666667
mb_albumartistid: 9a7f8969-387f-4161-b643-4b0e733f8d64
mb_albumid: e9166ebf-c7f6-4aa8-9a79-96619390f55a
mb_artistid: 9a7f8969-387f-4161-b643-4b0e733f8d64
mb_releasegroupid: 503804fe-8b3d-36e4-8fcc-bb29f46626ca
mb_trackid: 8dcd4fc4-f293-48c4-99af-f769dc8dabb6
media: CD
month: 10
original_date: 2004-01-01
original_year: 2004
samplerate: 44100
script: Latn
title: Y la perdi
track: 13
tracktotal: 17
year: 1947
(py3) juh@sokrates:~$ beet ls date:1947-10-07
(py3) juh@sokrates:~$
beet got the date info, but does not find the file in a query.
Can you find the item by querying on the “year” field? Have you tried listing the date with beet ls -f?
With year I can find it, date does not seem to be a valid field.
beet ls Y la Perdi -f '$date'
gives
$date
instead of the string.
Ah yes, good point—we don’t currently have a date field in the beets database; the release date is stored separately as $year, $month, and $day. It shows up in the info output (without -l), however, because we do have a file-level abstraction for it.