file names and file formats for audio fields

[Jon C]

I'm putting together a sample FLEx project (based on Lexique Pro's
Bambara sample) that I hope to export to LIFT and use for testing a
prototype flash card tool. But I'm a little uncomfortable setting up
the audio fields. So, partly, I'd like some advice. And partly, I hope
the developers will consider improving the file path features some
more. (I'm testing with FW 7.2.2, BTW.)

Ok, my current goal is to extract up to two audio filenames and one
picture filename from each entry, and generate flash cards:
- one sound recording of the lexeme form's pronunciation (pulled from
an entry field/object)
- one sound recording of the first example sentence (pulled from the
first sense that has an example)
- one picture (pulled from the first sense that has a picture)
- (I'll also include some content from plain-text fields, of course.)

PROBLEM 1: WAV only. To keep the sample files small, I recorded the
audio clips as MP3 files. But FLEx then required me to convert them to
WAV before I could use them. People who use digital recorders often
end up with other formats than WAV (typically MP3?), so this will be
an obstacle for them, and for anyone who can't afford the bandwidth
and disk space WAV requires.

To add recordings to an example sentences, I first created an audio
"writing system". (BTW, WeSay now calls these "input systems", which
is quite intuitive.) Then I used shift-click to link that file to the
audio input system of an example sentence. This worked, but...

PROBLEM 2: FLEx made a *copy* of my file (biriki.wav) and gave it a
less-friendly name, based on a guid, presumably (634683385012656250A
LexExampleSentence.wav). For people who have collected lots of data
outside of FLEx and want to bring it in, I really doubt this is what
they would want. (Are there compelling reasons? If one reason is
enforcing uniqueness, doesn't the file system already do this?) FYI,
clicking X to delete the audio deletes the linked file, so at the
moment it only deletes the copy that FLEx made.

The audio for examples was the hard part. Inserting images into senses
was easy. FLEx stores an absolute path in the Picture-FileName
field(s) and leaves the filenames as they were--and doesn't make a
copy. This is quite nice, although the system seems too rigid to me.

PROBLEM 3: Pictures are stored using absolute paths, and these cannot
be edited (neither by hand nor by bulk edit). So, the files can't be
moved around on the hard drive, right?

My dilemma now is where to store the audio for the Lexeme Form's
pronunciation. The old way, is to store it under Pronunciation in the
Media File field. (Rigid, but nice and clean, like Picture.) But with
the advent of audio input systems, maybe Media File is somewhat
obsolete? That is, storing it in an audio input system of a field like
Lexeme Form is the newer way. And, of course, it would be nice to be
consistent with the way I'm storing example sentence audio.

Any suggestions?

BTW, I really like the fact that under the hood, the new solution can
handle both relative and absolute paths, and either forward slashes or
backslashes. These paths can't be hand-edited (yet?), but they *can*
be bulk-edited, so it is possible to move the files around if you're
comfortable with bulk edit and basic regex. (Not sure if we're really
'supposed to' do this, though. E.g. I suspect FLEx can only auto-
backup the media files stored under LinkedFiles.)

Jon

[Aaron Broadwell]

Wow!  Talk about two minds on the same wavelength :-)

We also started to experiment in the last week or two with the Audio writing system, but ran into a related set of problems.  One is that we had previously stored our hundreds of sound files (created with Audacity) on a network drive, and we don't necessarily want to include all these files in every back-up, since this will make the back-up file enormous.  So we did not click the "Include sound files" box when we made the back-ups.

The Audio writing system field is much, much quicker than switching to  a separate program.  However -- the file names are very odd, and we seem to have no control over them.  All the sound files for examples are labeled something like nnnnnnnnnnnnLex Example, so we cannot tell by looking at the file name which entry it goes to.

We also notice an odd phenomenon.  If we configure the column in the middle pane of Lexicon edit to show the Audio writing system, we can see the name of the file, but if the local computer is not connected to the directory where the file is located, the right pane doesn't give any indication that a sound file is linked to this field.  In fact we could not figure out where the files we had recorded had gone until we configured the columns in this way and could see the file names.

We'd appreciate advice -- we are reluctant to continue recording sounds with the nifty new Audio field when we don't feel that we have good control over their file names, locations, and the display.   A possible suggestion -- perhaps in the rightmost lexicon pane, an Audio field could give you the option of displaying either a triangular play icon or a file name?

[Cory Shain]

I'd like to throw my wholehearted agreement behind the request for greater control over the treatment of audio files by the audio writing system variant. It's a very useful innovation, especially for inserting recordings of example sentences, which I find especially important in light of the increased trend toward collecting documentary linguistic data, but its two drawbacks are major: 1) it necessarily renames the files unintelligibly, and 2) it can't read from the source file and must make a copy, even if the source file is already in the destination folder, doubling the space taken up by the same information on the hard disk. I'm going to have LOTS of short recordings in my database that I want to keep with transparent filenames, so this is potentially a deal-breaker for me. But the only other option, inserting a new entry-level pronunciation field for each recording, makes it impossible to clearly index the recordings to the example sentences they contain, and makes it look like each recording is an alternative pronunciation of the entry's headword, which is not the case. Right now I can't decide which evil is the lesser. In order to have a properly organized database AND audio files with transparent-enough names to be useful for documentary purposes, it would be very helpful if the audio writing system variant allowed 1) selecting the source file WITHOUT copying and renaming it and/or 2) controlling the naming template used.

Thanks!

Cory