# Composer Field Not Uploading Correctly **URL:** \ **Category:** Support\ **Created:** [April 30, 2025, 10:22am UTC](https://community.mp3tag.de/t/composer-field-not-uploading-correctly/68351 "2025-04-30T10:22:45Z")\ **Posts on this page:** 20\ **Page:** 2
**Author:** ![ohrenkino](https://community.mp3tag.de/user_avatar/community.mp3tag.de/ohrenkino/32/4843_2.png) [@ohrenkino](https://community.mp3tag.de/u/ohrenkino)\ **Post date:** [April 30, 2025, 9:02pm UTC](https://community.mp3tag.de/t/composer-field-not-uploading-correctly/68351/21 "2025-04-30T21:02:18Z")
> [@make-nz](#): > > have `trim()` $trim() works on the contents of a field, not the fieldname. $trim() also works only in generating format strings but not matching format strings - for the import of data from files a matching format string is required. See here for more descriptions of format strings: > **[Format Strings and Placeholders – Mp3tag Documentation](https://docs.mp3tag.de/format/)** > > Documentation on format strings and placeholders to describe the structure of file names and imported data. Mp3tag is the universal Tag Editor. esp. the part " Format strings are used in two ways in Mp3tag, **matching** format strings and **generating** format strings. Matching format strings are used for simple pattern matching of existing strings, e.g., file names to import tags from or lines in a text file that describe tag contents to be imported. Generating format strings are used to create new strings, e.g., file names when renaming, field contents when formatting tag fields, data when exporting, but also file names for playlists or cover images that are parameterized with tag contents. Generating format strings can be combined with [scripting functions](https://docs.mp3tag.de/scripting)." ---
**Author:** ![make-nz](https://community.mp3tag.de/user_avatar/community.mp3tag.de/make-nz/32/18236_2.png) [@make-nz](https://community.mp3tag.de/u/make-nz)\ **Post date:** [April 30, 2025, 9:20pm UTC](https://community.mp3tag.de/t/composer-field-not-uploading-correctly/68351/22 "2025-04-30T21:20:36Z")
> [@ohrenkino](#): > > $trim() works on the contents of a field, not the fieldname. There (fieldname) it's the biggest issue, as humans will not see trailing white space - as you pointed it out, too. I'm referring to `trim()` in general if/how a program implements it is not something a user should have to know, or worry about, in my opinion. ---
**Author:** ![MotleyG](https://community.mp3tag.de/user_avatar/community.mp3tag.de/motleyg/32/440_2.png) [@MotleyG](https://community.mp3tag.de/u/MotleyG)\ **Post date:** [April 30, 2025, 9:44pm UTC](https://community.mp3tag.de/t/composer-field-not-uploading-correctly/68351/23 "2025-04-30T21:44:51Z")
Modification date is a OS file system function. Usually any time a file is changed for any reason this date reflects the current date and time. This is with or without using mp3tag. In the options for mp3tag there is a setting that you can check so that this date is not changed when saving from mp3tag. However this means most other software will not find any reason to update. Since you are seeing the genre update I doubt this is the cause here. I am more inclined to believe that additional characters are being used during the import as has been discussed already. ---
**Author:** ![MotleyG](https://community.mp3tag.de/user_avatar/community.mp3tag.de/motleyg/32/440_2.png) [@MotleyG](https://community.mp3tag.de/u/MotleyG)\ **Post date:** [April 30, 2025, 9:55pm UTC](https://community.mp3tag.de/t/composer-field-not-uploading-correctly/68351/24 "2025-04-30T21:55:54Z")
> [@mattiebear](#): > > All 265 tracks state that conductor field correctly within mp3tag but the conductor field is not completed outside of mp3tag. I have tested this now in three different softwares. Clearly if three different player programs are unable to see the updated tag info for any field, there is a mismatch between what is expected and what has been written. I can very much confirm that both the composer and conductor fields when saved directly from mp3tag are very much visible in MusicBee using mp3, FLAC, and m4a files when tested on my side. This leads back to something in your environment that is causing the mismatch to occur. Since you are depending on an import from a csv file to harness this external data you will need to comb through that to determine if the error can be found in the naming there. As an alternative test, use the tag panel in mp3tag to manually type in the Composer and Conductor data and save it. (You may need to add these fields to your panel as I cannot recall if they are there by default). For the test file, can MusicBee now see these changes? If yes the problem is definetly in your csv source data. ---
**Author:** ![make-nz](https://community.mp3tag.de/user_avatar/community.mp3tag.de/make-nz/32/18236_2.png) [@make-nz](https://community.mp3tag.de/u/make-nz)\ **Post date:** [April 30, 2025, 9:57pm UTC](https://community.mp3tag.de/t/composer-field-not-uploading-correctly/68351/25 "2025-04-30T21:57:03Z")
> [@MotleyG](#): > > additional characters are being used during the import as has been discussed already. Me too, just tested this, as it wouldn't have crossed my mind, being possible: ![image](https://community.mp3tag.de/uploads/default/original/3X/a/f/af3db75ff8bfb97946cb8938cb6278c7d61eef00.png) ---
**Author:** ![make-nz](https://community.mp3tag.de/user_avatar/community.mp3tag.de/make-nz/32/18236_2.png) [@make-nz](https://community.mp3tag.de/u/make-nz)\ **Post date:** [April 30, 2025, 10:22pm UTC](https://community.mp3tag.de/t/composer-field-not-uploading-correctly/68351/26 "2025-04-30T22:22:42Z")
Well, I again will admit, this is not soo easy to spot,figure,understand… ![My MusicBee test](https://community.mp3tag.de/uploads/default/original/3X/5/d/5d580db8c048fe1b8937f5460d207cad3ac0c895.png) ```auto //Just some pseudocode during the import to cleanup fieldnames $fieldname = str_replace('%', '', $import_fieldname); $fieldname = '%'.trim($fieldname).'%' ``` Is that not possible in mp3tag, sanitizing a _fieldname_ seems crucial, to me. ---
**Author:** ![make-nz](https://community.mp3tag.de/user_avatar/community.mp3tag.de/make-nz/32/18236_2.png) [@make-nz](https://community.mp3tag.de/u/make-nz)\ **Post date:** [April 30, 2025, 10:50pm UTC](https://community.mp3tag.de/t/composer-field-not-uploading-correctly/68351/27 "2025-04-30T22:50:10Z")
So it turns out _Composer fieldname_ needed to be case sensitive in my test import: ![My test import](https://community.mp3tag.de/uploads/default/original/3X/b/f/bf4de4648997a8ab50b54c22966eb437057180f5.png) Seeing the result… who is not to be confused? ![Composer becomes COMPOSER :-/](https://community.mp3tag.de/uploads/default/original/3X/d/0/d0a281e897678d1a4d370c5b391d24724a3984f2.png) And in MusicBee: ![Now in MusicBee](https://community.mp3tag.de/uploads/default/original/3X/b/5/b58bfb968d56eca971a5e81f67b75fac4f25946b.png) @mattiebear I feel with you, if this is what happened in your import, would frustrate me too. And I'm glad I learned something -- hope you read this and get your imports to work soon. ---
**Author:** ![MotleyG](https://community.mp3tag.de/user_avatar/community.mp3tag.de/motleyg/32/440_2.png) [@MotleyG](https://community.mp3tag.de/u/MotleyG)\ **Post date:** [May 1, 2025, 12:29am UTC](https://community.mp3tag.de/t/composer-field-not-uploading-correctly/68351/28 "2025-05-01T00:29:07Z")
Field name _placeholders_ for actions. are always lower case and enclosed within percent symbol characters such as `%composer%` or `%conductor%` for mp3tag formatting. Reference simply to their names is in all caps such as `COMPOSER` or `CONDUCTOR`. ---
**Author:** ![ohrenkino](https://community.mp3tag.de/user_avatar/community.mp3tag.de/ohrenkino/32/4843_2.png) [@ohrenkino](https://community.mp3tag.de/u/ohrenkino)\ **Post date:** [May 1, 2025, 6:17am UTC](https://community.mp3tag.de/t/composer-field-not-uploading-correctly/68351/29 "2025-05-01T06:17:14Z")
I do not think that there is a rule about the case of a field name. Here in the forum we try to use a certain style to distinguish between a semantic reference to e.g. a composer, the contents of the field %composer% or the field name COMPOSER. Some applications require field names to be all capitals if the field names are not identified by tokens but by their real name which is e.g. the case for vorbis comments in flac files. These field names can adapted with an action of the type "Case conversion" for \_FIELDNAME. For a discussion on the case of field names, please open a new thread. ---
**Author:** ![mattiebear](https://community.mp3tag.de/letter_avatar_proxy/v4/letter/m/e47c2d/32.png) [@mattiebear](https://community.mp3tag.de/u/mattiebear)\ **Post date:** [May 1, 2025, 1:00pm UTC](https://community.mp3tag.de/t/composer-field-not-uploading-correctly/68351/30 "2025-05-01T13:00:14Z")
I have just tried to upload the csv and a couple of mp3 files for you but it won't let me here? ---
**Author:** ![LyricsLover](https://community.mp3tag.de/letter_avatar_proxy/v4/letter/l/c6cbf5/32.png) [@LyricsLover](https://community.mp3tag.de/u/LyricsLover)\ **Post date:** [May 1, 2025, 1:02pm UTC](https://community.mp3tag.de/t/composer-field-not-uploading-correctly/68351/31 "2025-05-01T13:02:09Z")
Please upload it to one of the public and free transfer websites (like [WeTransfer.com](http://WeTransfer.com) or [swisstransfer.com](http://swisstransfer.com)) and then share the link to your upload here. ---
**Author:** ![mattiebear](https://community.mp3tag.de/letter_avatar_proxy/v4/letter/m/e47c2d/32.png) [@mattiebear](https://community.mp3tag.de/u/mattiebear)\ **Post date:** [May 1, 2025, 1:02pm UTC](https://community.mp3tag.de/t/composer-field-not-uploading-correctly/68351/32 "2025-05-01T13:02:16Z")
This is the format string being used: %filename%,%conductor%,%genre% ---
**Author:** ![mattiebear](https://community.mp3tag.de/letter_avatar_proxy/v4/letter/m/e47c2d/32.png) [@mattiebear](https://community.mp3tag.de/u/mattiebear)\ **Post date:** [May 1, 2025, 1:05pm UTC](https://community.mp3tag.de/t/composer-field-not-uploading-correctly/68351/33 "2025-05-01T13:05:22Z")
I've uploaded the csv and 3 mp3 files as examples: > **[1955 Conductors.csv](https://wetransfer.com/downloads/537d5d6bfd28bd8c6153127bf35cef1420250501130434/a8a571?t_exp=1746363874&t_lsid=fa2e133c-d331-4f10-ae26-ac7bbe8566a5&t_network=link&t_rid=ZW1haWx8YWRyb2l0fGUyYjUzYmQ4LWY1MzEtNDdlMi1hYTUzLTE0YThiNmRkZGJhYQ==&t_s=download_link&t_ts=1746104687)** > > 4 files sent via WeTransfer, the simplest way to send your files around the world ---
**Author:** ![LyricsLover](https://community.mp3tag.de/letter_avatar_proxy/v4/letter/l/c6cbf5/32.png) [@LyricsLover](https://community.mp3tag.de/u/LyricsLover)\ **Post date:** [May 1, 2025, 1:09pm UTC](https://community.mp3tag.de/t/composer-field-not-uploading-correctly/68351/34 "2025-05-01T13:09:49Z")
What I see for "Mister Sandman" are two fields: CONDUCTOR and CONDUCTOR **S** ![image](https://community.mp3tag.de/uploads/default/original/3X/7/2/7217eca4957aedc9abfa584a85c7b5cd50ed5868.png) For "Count Your Blessings Instead Of Sheep" ![image](https://community.mp3tag.de/uploads/default/original/3X/c/9/c982922e39b965c3f67eab20866c353629e44692.png) Are these two songs showing the CONDUCTOR / CONDUCTORS correctly in MusicBee and MediaMonkey? If yes, I think it should be [CONDUCTOR](https://docs.mp3tag.de/mapping/#conductor) (singular). ---
**Author:** ![mattiebear](https://community.mp3tag.de/letter_avatar_proxy/v4/letter/m/e47c2d/32.png) [@mattiebear](https://community.mp3tag.de/u/mattiebear)\ **Post date:** [May 1, 2025, 1:12pm UTC](https://community.mp3tag.de/t/composer-field-not-uploading-correctly/68351/35 "2025-05-01T13:12:17Z")
So Mister Sandman I updated manually as a test, so it shows correctly in both. Count Your Blessings Instead Of Sheep does not show the Conductor in MusicBee. ![image](https://community.mp3tag.de/uploads/default/original/3X/9/f/9fae5f28dc9aa79484954a6ad0424aadb809ef1e.png) As for there being Conductor and Conductors, I did this in error trying to fix the problem myself before asking for help as a reference on another sources said the tag was conductors rather than conductor. ---
**Author:** ![LyricsLover](https://community.mp3tag.de/letter_avatar_proxy/v4/letter/l/c6cbf5/32.png) [@LyricsLover](https://community.mp3tag.de/u/LyricsLover)\ **Post date:** [May 1, 2025, 1:19pm UTC](https://community.mp3tag.de/t/composer-field-not-uploading-correctly/68351/36 "2025-05-01T13:19:29Z")
> [@mattiebear](#): > > This is the format string being used: > > %filename%,%conductor%,%genre% This cannot work because %filename% imports your value in the metadata field FILENAME: ![image](https://community.mp3tag.de/uploads/default/original/3X/b/7/b74836257e039c61f7444bdee75155f51d42bb3f.png) What you would have to use as format string for the input from CSV is `%_filename_ext%,%conductor%,%genre%` ---
**Author:** ![mattiebear](https://community.mp3tag.de/letter_avatar_proxy/v4/letter/m/e47c2d/32.png) [@mattiebear](https://community.mp3tag.de/u/mattiebear)\ **Post date:** [May 1, 2025, 1:20pm UTC](https://community.mp3tag.de/t/composer-field-not-uploading-correctly/68351/37 "2025-05-01T13:20:25Z")
I'll try that now, bear with. (Oddly you say it cannot work but it updated all the genre data using that csv?) ---
**Author:** ![mattiebear](https://community.mp3tag.de/letter_avatar_proxy/v4/letter/m/e47c2d/32.png) [@mattiebear](https://community.mp3tag.de/u/mattiebear)\ **Post date:** [May 1, 2025, 1:21pm UTC](https://community.mp3tag.de/t/composer-field-not-uploading-correctly/68351/38 "2025-05-01T13:21:06Z")
The method I used works, the method you provided gives this: ![image](https://community.mp3tag.de/uploads/default/original/3X/6/9/6929fb154b0e52af38891021b7662c72801eb89e.png) ---
**Author:** ![mattiebear](https://community.mp3tag.de/letter_avatar_proxy/v4/letter/m/e47c2d/32.png) [@mattiebear](https://community.mp3tag.de/u/mattiebear)\ **Post date:** [May 1, 2025, 1:22pm UTC](https://community.mp3tag.de/t/composer-field-not-uploading-correctly/68351/39 "2025-05-01T13:22:59Z")
Just to let you know make-nz, I tried using %Conductor% instead and it didn't change the result (still not visible in MusicBee) ---
**Author:** ![LyricsLover](https://community.mp3tag.de/letter_avatar_proxy/v4/letter/l/c6cbf5/32.png) [@LyricsLover](https://community.mp3tag.de/u/LyricsLover)\ **Post date:** [May 1, 2025, 1:24pm UTC](https://community.mp3tag.de/t/composer-field-not-uploading-correctly/68351/40 "2025-05-01T13:24:25Z")
To get usable results, please clear your test songs every time completely from MusicBee and MediaMonkey. Then import your new/updated version. Otherwise you don't know if the new file was imported and the metadata refreshed or of they are still displayed from the internal database. [Previous page](https://community.mp3tag.de/t/composer-field-not-uploading-correctly/68351.md?page=1) [Next page](https://community.mp3tag.de/t/composer-field-not-uploading-correctly/68351.md?page=3)