mediaarea / bwfmetaedit Goto Github PK

I am reorganizing my library of 10,020 sounds, including embedding metadata. I would

1. Open the folder in ME.
2. Export a Core.csv
3. Edit Core.csv in excel (ensuring excel imported everything as-is)
4. Save the edit as Core-New.csv
5. Close all files in ME.
6. Import Core-New.csv
7. Verify the correct info was being changed by scanning for green boxes.
8. Save changes.

This would sometimes bring up a "Saving" progress bar. Other times it wouldn't. At some point during the save, if there were enough changes(I don't know the exact cutoff, more on that later), the program would instantly close, with no error messages.

Some number of files would have had their metadata changed successfully. No bwfs would be corrupted, so in theory I could just run the same Core-New.csv again and again. Instead, I chose to split the CSV file into parts and run each part.

2000 line CSV - 100% fail rate
1000 line CSV - ~30% fail rate
500 line CSV - ~10% fail rate
200 line CSV - 0% fail rate

Recall that a "fail" just means retrying the CSV one or more times. I settled for 1000 line CSVs which didn't take too long to process all the files.

It should be noted that I don't know what triggers the crash. It could either be number of fields being saved or number of files being changed.

Tech specs:
Updated Windows 10
BWF MetaEdit v1.3.1
16GB RAM
Total RAM usage 40% - 60% at crash. Unlikely to be RAM related.
Most wav files only a few MB each.
No errors on import, either in the Tech > Errors column or the in-app error log

I didn't realize there was an option for a log file. I tested everything again with the log file active. I failed to repro. ME changed metadata for nearly 10k files successfully. Two variables were different:

1. Logging was turned on. (It's possible but unlikely that writing to the log each time gave the processor enough buffer to finish the job. I've seen this happen in other programs.
2. I used Goolge Sheets instead of Excel to edit and generate the Core New.csv (Unlike Excel, it has an upfront option during import to leave the data completely untouched. It's possible there was some kind of escaped character Excel was exporting wrongly, but now that my files are properly stamped I don't want to continue testing)

For CodingHist, users have the option to save or load text. Currently it's not working (for me, Ubuntu 18.04) or working incorrectly (for Dave, macOS, it saves the first line only).

Overall though, this feature doesn't provide a lot of value. I think instead of fixing it, it could be deprecated entirely.

I think it's something involving the Load/Save file options in particular with CodingHist, because other segments with Import/Export do work successfully, when they are general text fields and not a specific form with dropdown menus. It probably has something to do with the strict required schema.

If anyone strongly disagrees, please sound off in the comments!!!

Open a valid wav file with no bext, open the coding history ui and go to "free text".
Paste in this text

A=ANALOGUE,M=mono,T=IRENE3D;LacquerDisc;78RPM
A=PCM,W=32,M=dual-mono,T=Weaver;Asus;Windows7
A=PCM,F=96000,W=32,M=dual-mono,T=iZotopeRX5;Asus;Windows7

The free text here is all on one line and rather unreadable.

Toggle between the "R98 editor" and "Free Text", each toggle adds more and more prefixes to each value.

Hi,

On Win 10x64, opening a file with a UTF-8 accent like

Gravats débris pierre.wav

produced this error:

2019-06-18 17:17:39 E:\Bureau\Gravats débris pierre.wav: File does not exist

I think file has to be escaped somewhere.

Meanwhile, I'll avoid any non-ASCII characters.

Thanks for your support !

Similar to the points raised in #104:

Adding data can be cumbersome, requiring several clicks. Several users have requested that they have the ability to copy and paste across cells, much like in spreadsheet software like LibreCalc or Excel.

@JeromeMartinez Is this possible? I can't quite tell from the feedback received in #104.

Starting this issue for discussion and mockups about reviewing the user interface of bwf metaedit, discussion and prioritization of any enhancements, etc.

For instance open a valid wav file and set "Originator" to 😎. The interface will show a warning because of the non-ascii character. Close the edit interface and the warning about the issue is not-visible, just a green cell to be saved. I suggest here to overlay an orange exclamation point over the right edge of the field with a mouse over of the same warning message shown in the field-edit ui.

I propose a value or error_detail which could give a more verbose statement about the truncation error. For instance, list all chunks provide size declarations to extend beyond EOF: "The RIFF chunk should be X bytes, but is Y bytes. The data chunk should be X bytes, but is Y bytes."

I suggest to show this value as a mouse-over of the "Errors" cell in the "Tech" view, and added as a line following the error value in the File view. In the CLI output include the error_detail as a parenthetical after the error message, such as:

2020-04-18 11:17:59 1_truncated.wav: invalid Wave: truncated (The RIFF chunk should be X bytes, but is Y bytes. The data chunk should be X bytes, but is Y bytes.)

Hi !

I have some file which display this in the console: invalid Wave: truncated

The metadata displays just fine in other application I use, like REAPER.

If other apps can display this right, maybe BWFMetaEdit is a bit too strict ?
Or, how could this be fixed right on the file ?

Thanks for your support !

Using version 1.3.2 in Ubuntu I have noticed that the text explanations that are displayed when a user hovers their mouse over a BEXT element seem to have gotten a bit garbled.

The 'FADGI Recommendations' text here: https://github.com/MediaArea/BWFMetaEdit/blob/master/Source/Resource/Documentation/bext.html#L23

Actually seems related to the guidelines for 'Originator' rather than 'Description.'

Similarly, the 'FADGI Examples' here:
https://github.com/MediaArea/BWFMetaEdit/blob/master/Source/Resource/Documentation/bext.html#L91

Are the examples given in the FADGI documentation for 'Originator,' not 'Originator Reference.'

For BWFME users, copying and pasting across fields is difficult. It involves double-clicking, selecting and copying text, saving, going to the next row, double-clicking, and pasting text.

Is it possible to have the editing occur in-line, without creating a new pop-up window? This would save time and simplify the interface substantially.

This is true across views -- File, Tech, and Core.

The pop-up does provide extra information in the context of a learning tool -- it explains what the requirements are. But for advanced and regular users, they already have an understanding of the requirements and just want to add/edit data quickly.

With latest snasphot, on Ubuntu 16.04, when double click on the .deb install silently fails.
with dpkg, "missing libqt4-gui".
Better to switch to Qt5 now at least with this version of Ubuntu.

Currently you can click into a field to select a row and then choose "File>Close file"; however this doesn't work all the time since not all files are editable and then no field can be selected. Users have suggested a "Close file" button per row to remove the file from the table or prompt for that file to be saved if there are unsaved changes for that file.

Currently clicking on a table column header, sorts the list, toggling between an alphabetical ascending to alphabetical descending. I suggest that an Alt-Click would toggle to numerical ascending to numerical descending. For instance if the list was 1.wav 11.wav 2.wav

Open a valid file with bext version 1.
Double click on the value of the 'bext" column, make no change but click "OK".
Now the value of the "bext" column is highlighted green as if a change is requested but the value is the same.

Bonus bug: while the bext value is green and says "Version 1", toggle to Core view and then back to "Tech" view, now it says "Version Version 1".

Hi,

I noticed a difference with injecting IART from the GUI version and IART from the CLI version (tested on windows 10 x64, v1.3.8 of BWFMetaEdit)

In the CLI version, LIST chunks isn't last chunk as it is supposed to be, and there is a mysterious FLLR chunk just after that.

The following image shows the difference: on top, BWFMetaEdit GUI version of IART = X-Raym injection, and same below but with CLI.

It is surprising that the two versions output different results.

Sure thing is that CLI version is wrong cause metadata written this way are not recognized by windows explorer (but they works in less sensitive softwares)

How come this difference ?

Thanks for your support !

In the preferences pane, in the MD5 section, provide a checkbox to adjust the endianness of how the md5 is shown. For example, Wavelab uses this md5 value but in the opposite endianness

Using slightly non EBU R98 Compliant values in coding history is resulting in diverging behaviors within the GUI. When viewing a file that contains the value A=ANALOG (using all caps US spelling) the editor will default to freetext mode and warn that the value is not complaint due to the US vs UK spelling difference. This seems a good way to handle this situation.

However, when opening a file that contains A=Analog (US spelling and not upper-case) the viewer will default to the dropdown mode and erase that field entirely upon switching over to the plain text view (Unless a compliant value is selected). It seems that this would be another instance where defaulting to plain text view and warning about compliance would be beneficial. (Along with perhaps expanding accepted FADGI values to take regional spellings into account).

File containing A=Analog,M=mono,T=Etc. defaults to this:

Which leads to this:

The TimeReference input value in the GUI seems to be limited to a 32 bit unsigned integer. If the WAV file has a sample rate greater than 48KHz, you can hit the limit.

At 96000Hz, if you input a timecode in the TimeReference (translated) box that's greater than 12:25:39.242, the timecode will change to that value and the TimeReference value will change to 4294967295. Similarly, you can't input a TimeReference value greater than 4294967295.

This was tested in the 64 bit Windows version of the GUI. The 64 bit Windows version of the CLI doesn't have the same issue.

presently if a file is truncated the fmt data is hidden

When I have a list of files, in File window, scrolling to the end will freeze and crash BWFMetaedit, with the only option for me to force quit to start again.
Mac OS 10.14.6, BWF Metaedit 20.05

In the file view, the XMP, aXML, iXML text should be buttons that open a pop-up box where users can view, edit, or add metadata.

Under "Preferences>Default View", I suggest a radio button list of sort options for the "Filename" column of the Tech and Core tables. "Sort by FileName" or "Sort by FilePath".

For File view, it looks a little clumpy. Could you add some kind of line or barrier between each file? For example, with CSS you can add border-bottom: 2px solid black to the <div>, perhaps something similar will work for this.

Also, I think it'd be better if the filepath was in black and with a bold font-weight, to further emphasize the separation between files.

This is super nit-picky, but Length is spelled as "lenght" in this view and perhaps some others.

It seems to be used consistently so I suppose it's not harming anything, but if you expect to use "length" anywhere else, it might cause a problem by accident?

In Tech/Core views, the Filename tooltip text expands out very long. The other descriptors include linebreaks. This also needs some linebreaks or some way of having a maximum width.

Hi,

I'm on Win 10 x64.

When I set a LIST-INFO field like IART (artist name), it appears truncated in windows explorer column display and file properties.

Though, the information seems valid for BWF MetaEdit or other software capable of reading LIST-INFO. But I noticed that adding \x00 may solve the issue (I do that with a python script I made) (and also, size chunk have to be updated).

Here is a demo, using Riffpad to inspect chunks.:

Do you think it is a windows issue or a BWF MetaEdit one ?

Cheers !

EDITED: 2018-06-15: new screenshot

From EBU Tech 3285 v2, page 13:

"If any of the loudness parameters are not being used then their 16-bit integer values shall be set to 7FFFh, which is a value outside the range of the parameter values."

With BWF MetaEdit 1.3.1, when opening a wave file, setting the BWF version to 2, and saving it, all loudness values are set to 0000h instead of 7FFFh, equalling the valid interpreted value of 0.0, which may not be true for the file.

Besides that, it's a great tool you've got here, thank you for making it available, and maintaining it.

Both CLI and GUI are unable to delete old, longer free-text CodingHistory.

In other words, if I have a long free text coding history such as

“LONG CODING HISTORY”

and I want to update it to

“Short history”,

once I save the changes, it becomes

“Short historyHISTORY”

I.e., I can overwrite characters, but the old characters “stick out” afterwards.

Marcos

Hi,

Currently from CLI, I can only see a function to export iXML of a wav to a new file, but no way to just return this iXML as a string.

Do I miss anything ?
Could it be added for the future ? 😃

Thx !

The current green and red are a bit intense, and also make some script hard to read (when in black or grey).

Here are the changes I propose:

Current green -> 90ee90
Current red -> #fc6744

I think the "active use" blue is ok as-is.

This should also work well for people who are colorblind, because the green one is brighter than the more muted red, luma-wise.

Related to #93, I suggest we set an application preference option of "Allow changes to invalid files" with a default to false.

Suggested behavior:
If "Allow changes to invalid files" = false, then
If someone tries to save changes to a list of files that includes an invalid file, I suggest that changes for valid files are saved, but an error message "Changes not saved to $filename because this file is invalid. If you want to force a change to this file, please enable Allow changes to invalid files, but be aware that edits to invalid files may have unexpected results or remove the indication that the file is invalid."

Currently large tooltips appear when mousing over the entire column. These explain what the field is for but obscure data entry and data review. I suggest having these tooltips constrained to mousing over the column header rather than the entire column.

From earlier discussions, BWF MetaEdit currently presents all edit and review in a series of tables but there's no single form in the ui to see all details of one file. I propose design of such a form which the same field components as the tables but arranged in a form which shows the contents of the chunks for review and edit.

For XMP, aXML, iXML, it would be nice if these were minimally validated as XML. Would something like that be possible? It doesn't have to validate against their specs, but just check if there are open/closed tags and that all data is enclosed in them.

Occasionally files seem to present duplicate fields and have two WAVE chunks. Reject, warn, avoid creating. May be related to beginning/end data write option.

W:\ARCHIVESNAS1\INGEST\03 READY TO INGEST\Cooper Union Forum\WNYC-COOP-1969-uu-uu-152433.1 Symbolism.wav
00000000 7CE8C2E8 WAVE
0000000C 00000010 fmt
00000024 7CE8A000 data
7CE8A02C 000002CE WAVE
7CE8A302 00000495 iXML
7CE8A7A0 00001665 _PMX
7CE8BE0E 0000027A INFO
7CE8BE1A 0000002E IART
7CE8BE50 0000005E ICMS
7CE8BEB6 00000078 ICMT
7CE8BF36 00000032 IKEY
7CE8BF70 00000016 IMED
7CE8BF8E 0000000E ISFT
7CE8BFA4 00000042 ISRC
7CE8BFEE 00000068 ISRF
7CE8C05E 00000019 ITCH
7CE8C080 00000008 IGNR
7CE8C090 00000258 FLLR

Suggested fix, circa line 92:

    #ifdef UNICODE
        WCHAR Path[MAX_PATH];
    #else
        char Path[MAX_PATH];
    #endif

Starting a ticket here as this issue has come up several times in discovery interviews. The "cue " chunk contains information that often has a descriptive relationship to the metadata of the bext and LIST-INFO chunk. I'm uncertain if it is in scope of BWF MetaEdit to support editing this chunk but I think it could be useful to view it in BWF MetaEdit.

In file view, there are several useful new features but they are too subtle. The +/- box, edit, save, x, and additional metadata all appear (at least for me, Ubuntu 18.04) as a very light grey and relatively small text (smaller than the data fields such as Version, Description).

Somewhat related, it'd be nice to have a visible scroll-bar on the right, otherwise it's not clear that scrolling is possible. It's more obvious on the Tech/Core views when there are many files, and is always present.

This can be seen in #105

duplicateFields.txt

When managing relatively large files BWF ME GUI often seems slow or unresponsive, or it crashes. Today BWF ME GUI 1.3.8 crashed more than once when trying to write into 17 files less than 200 MB each. In one of them it duplicated some fields (see attached file). I am using it with option to place chunks at end of file, since it seems faster.

Windows 10 Enterprise

When editing values in CodingHist, for some reason I have to double-click into the cell to get the dropdown menu to load. It would be better if a user didn't have to do that, and the drop-down menus would just appear without the need to double-click on them.

See #73 (comment). Currently BWF MetaEdit re-uses the FADGI logo and in some cases causes identify confusion.

For CodingHist, the "Mode" dropdown is limited to only four options. The way around this, for users with different Modes, is to switch to the Free text box and edit it there. Is there a way to have the existing dropdown options and also an additional free text field option?

Hi,

Currently, there is in-core= which add metadata from the specified Core file, and all the individual possibilities (in-core-Description= etc...).

It would be nice to have in-core-csv=, which could set metadata from a CSV string (and not a file). This way, if we have to set up multiples metadata, no need to call bwfmetaedit several times, or to dump the metadata as file first.

This function could update only specified file for eg:

Description,Loudness
This is my file,-4

Would only add the Description and Loudness fields.

or we could simply pass a single CSV line which would override any values (in this cases, pre-processing to add metadata values which needs to be preserved have to be done from a script).

What do you think about it ? :)

Cheers !

On BWF MetaEdit 1.3.8, dragging and dropping the CORE document into the GUI does not pull up any files. Importing the CSV "sometimes" works but other times produces the error "File does not exist" for all items in the document. This issue has been observed on multiple workstations. The workaround has been to drag the CORE document into the GUI only after all of the files have been loaded in.

Ability to select more than one field from a row and have the corresponding columns fill out with the values of each field.

(Received by email)

(...) that used the open quotation (hex 93) and close quotation (hex 94) characters in their data and it didn't translate well at all!

macmini:~ jerome$ cd bwfmetaedit/Project/QtCreator/
macmini:QtCreator jerome$ qmake
Info: creating stash file /Users/jerome/bwfmetaedit/Project/QtCreator/.qmake.stash
macmini:QtCreator jerome$ make
make: *** No rule to make target ../../Source/Resource/Image/FADGI/Logo.icns', needed by BWF MetaEdit.app/Contents/Resources/Logo.icns'. Stop.

Hi !

I'm trying to inject Loudness data from CLI, with --LoudnessValue="0" syntax,

but I only get an error message:

--loudnessvalue="0" is unknown.

According to source code, only some keywords are allowed: https://github.com/MediaArea/BWFMetaEdit/blob/master/Source/CLI/CommandLine_Parser.cpp#L445 .... and not loudness value.

But the LoudnessValue parameter is proposed by the bwfmetaedit --help

                        Fill files with:
--in-core=              data from the specified Core file
--in-core-remove        clear data (remove bext and INFO)
--BextVersion=          specified bext version
--Description=          specified bext description
--Originator=           specified bext originator
--OriginatorReference=  specified bext originator reference
--OriginationDate=      specified bext origination date
--OriginationTime=      specified bext origination time
--Timereference=        specified bext time reference
--UMID=                 specified bext umid
--LoudnessValue=        specified bext loundness value
--LoudnessRange=        specified bext loundness range
--MaxTruePeakLevel=     specified bext max true peak level
--MaxMomentaryLoudness= specified bext max mnomentary loundness
--MaxShortTermLoudness= specified bext maw short term loundness
--History=              specified bext history
--IARL=                 specified INFO IARL
--ISFT=                 specified INFO ISFT
--xxxx=                 specified INFO xxxx...

Are these Loudness and Peak keywords missing from the Parser ? Or is it a problem with the help ?
Unless I'm simply missing something ?

Thanks again for your support !