3 Configuration (intro)

Because of its flexibility, Cinelerra cannot be optimized without special configuration for your specific needs. Unfortunately, very few parameters are adjustable at compile time. Therefore, runtime configuration is the only option for most users because of the multitude of parameters available.
Below are configuration options as well as the supported API’s in GNU/Linux.
In Cinelerra, go to Settings->Preferences to see the options.

• 3.1 Environment variables
  These environment variables are recognized by Cinelerra
• 3.2 Audio drivers
  Information about the audio drivers
• 3.3 Video drivers
  Information about the video drivers
• 3.4 Playback
  Configuring parameters related to playback.
• 3.5 Recording
  Configuring parameters related to recording.
• 3.6 Performance
  Configuring parameters related to how fast things go.
• 3.7 Interface
  Configuring the user interface.
• 3.8 About window
  Viewing information about the program.

3.1 Environment variables

In UNIX derivatives, environment variables are global variables in the shell which all applications can read. They are set with a command like set VARIABLE=value. All the environment variables can be viewed with a command like env. Cinelerra recognizes the following environment variables:

• LADSPA_PATH
  If you want to use LADSPA plugins, this must be defined: a colon separated list of directories to search for LADSPA plugins. These are not native Cinelerra plugins. See section Ladspa effects.
• GLOBAL_PLUGIN_DIR
  The directory in which Cinelerra should look for native plugins. The default is ‘/usr/lib/cinelerra’ but you may need an alternate directory if you share the same executable directory among many machines via NFS. Plugins of different binary formats need to be in different directories.
• LANG and LANGUAGE
  Cinelerra can be localized to display menus and messages in many languages. Cinelerra language settings are normally read from your GNU/Linux language settings. To run Cinelerra on a language different than the one selected on your system just change the LANG and LANGUAGE environment variables.

For example, open a shell and type: export LANG=es_ES LANGUAGE=es_ES, then run cinelerra from the same shell. It will open set on the Spanish language.
Available languages are:

• en_EN - English
• es_ES - Espanol
• sl_SI - Slovenian
• fr_FR - Francais
• eu_ES - Euskera
• de_DE - German
• pt_BR - Brazilian Portuguese
• it_IT - Italian

If your distribution has only UTF-8 support (like Ubuntu), first you must create the language charset with this command:

localedef -c -i (language_prefix) -f (your ISO-8859 variant) (language_prefix).(your ISO-8859 variant)

This is an example for Italian language:

localedef -c -i it_IT -f ISO-8859-15 it_IT.ISO-8859-15

Then you can run cinelerra with this command:

env LANG=$(echo $LANG | sed -e s/UTF-8/(your ISO-8859 variant)/g) cinelerra

This is an example for Italian language:

env LANG=$(echo $LANG | sed -e s/UTF-8/ISO-8859-15/g) cinelerra

In some cases (e.g. if you compiled Cinelerra specifying a ‘--prefix=’ option different from ‘/usr/local’) the translated .po files are not installed. If you can’t run Cinelerra in your chosen language, try running the following commands before changing the LANG and LANGUAGE environment variables:

cd hvirtual
./configure prefix=/usr
cd po
sudo make install

3.2 Audio drivers

The audio drivers are used for both recording and playback. Their functionality is described below:

3.2.1 Sound driver attributes
3.2.2 OSS Notes about the OSS driver
3.2.3 OSS Envy24 Notes about the OSS driver for the Envy24 chip
3.2.4 Alsa Notes about the ALSA driver
3.2.5 Esound Notes about the ESound driver
3.2.6 Raw 1394 Notes about the Raw1394 driver
3.2.7 DV 1394 Notes about the DV1394 driver
3.2.8 IEC 61883 Notes about the IEC 61883 driver

3.2.1 Sound driver attributes

* Device path
Usually a file in the ‘/dev/’ directory which controls the device.

• Bits
  The number of bits of precision Cinelerra should set the device for. This sometimes has a figurative meaning. Some sound drivers need to be set to 32 bits to perform 24 bit playback and will not play anything when set to 24 bits. Some sound drivers need to be set to 24 bits for 24 bit playback.
• Port
  The IEEE1394 standard specifies something known as the port. This is probably the firewire card number.
• Channel
  The IEEE1394 standard specifies something known as the channel. For DV cameras it is always 63.
• Device
  The chosen device.
• Stop playback locks up
  This ALSA only checkbox is needed if stopping playback causes the software to lock up.

3.2.2 OSS

This was the first GNU/Linux sound driver. It had an open source implementation and a commercial implementation with more sound cards supported. It was the standard sound driver up to GNU/Linux 2.4. It still is the only sound driver which an i386 binary can use when running on an x86_64 system.

3.2.3 OSS Envy24

The commercial version of OSS had a variant for 24 bit 96 KHz soundcards. This variant required significant changes to the way the sound drivers were used, hence the need for the new driver.

3.2.4 Alsa

ALSA is the most common sound driver in GNU/Linux 2.6. It supports most of soundcards now. It takes advantage of low latency features in GNU/Linux 2.6 to get better performance than OSS had in 2.4, but roughly the same performance that OSS had in 2.0. Unfortunately ALSA is constantly changing. A program which works with it one day may not the next day. New wrappers are being developed on top of ALSA. We plan to support them at regular intervals, though not at every new release of a new wrapper.
ALSA is no longer portable between i386 and x86_64. If an i386 binary tries to play back on an x86_64 kernel, it will crash. For this scenario, use OSS.

3.2.5 Esound

ESOUND was a sound server that sat on top of OSS. It was written for a window manager called Enlightenment. It supports a limited number of bits and has high latency compared to more modern drivers, but it does have the ability to multiplex multiple audio sources. It is unknown whether it still works.

3.2.6 Raw 1394

The was the first interface between GNU/Linux software and firewire camcorders. It is the least reliable way to play audio to a camcorder and consists of a library on top of the kernel commands.

3.2.7 DV 1394

This is the second rewrite of DV camcorder support in GNU/Linux. This is the most reliable way to play audio to a camcorder and consists of direct kernel commands.

3.2.8 IEC 61883

3.3 Video drivers

The video drivers are used for video playback in the compositor and the viewer.

3.3.1 Video driver attributes
3.3.2 X11
3.3.3 X11-XV
3.3.4 X11-OpenGL
3.3.5 Buz
3.3.6 Raw 1394 video playback
3.3.7 DV 1394 video playback
3.3.8 IEC 61883 video playback

3.3.1 Video driver attributes

• Display
  The interface is intended for dual monitor displays. Depending on the value of Display, the Compositor window will appear on a different monitor from the rest of the windows.
• Device path
  Usually a file in the ‘/dev/’ directory which controls the device.
• Swap fields
  Make the even lines odd and the odd lines even when sending to the device. On an NTSC or 1080i monitor the fields may need to be swapped to prevent jittery motion.
• Output channel
  You may need a specific connector to send video out to devices with multiple outputs.
• Port
  The IEEE1394 standard specifies something known as the port. This is probably the firewire card number.
• Channel
  The IEEE1394 standard specifies something known as the channel. For DV cameras it is always 63.

3.3.2 X11

This was the first method of graphical display on any UNIX system. It just writes the RGB triplet for each pixel directly to the window. It is the slowest playback method. It is still useful as a fallback when graphics hardware can not handle very large frames.

3.3.3 X11-XV

This was an enhancement to X11 in 1999. It converts YUV to RGB in hardware with scaling. It is the preferred playback method but can not handle large frame sizes. The maximum video size for XV is usually 1920x1080.

3.3.4 X11-OpenGL

The most powerful video playback method is OpenGL. With this driver, most effects are done in hardware. OpenGL allows video sizes up to the maximum texture size, which is usually larger than what XV supports, depending on the graphics driver. To enable it you will need a binary built with OpenGL support. The configure option to enable OpenGL is ‘--enable-opengl’. You need a video card which supports OpenGL 2.0. Recent Nvidia video cards should work. You also need to use a video driver supporting OpenGL 2.0, such as Nvidia’s binary driver. To know if your video driver supports OpenGL 2.0, type the following command: glxinfo | grep "OpenGL version"

• Video driver supporting hardware OpenGL 2.0 rendering:
  OpenGL version string: 2.0.2 NVIDIA 87.74
• Video driver not supporting hardware OpenGL 2.0 rendering:
  OpenGL version string: 1.4 (2.0.2 NVIDIA 87.74)

OpenGL relies on PBuffers and shaders to do video rendering. The graphics driver must support OpenGL 2.0 and Cinelerra needs to be explicitly compiled with OpenGL 2.0 support. This requires compiling it on a system with the OpenGL 2.0 headers. PBuffers are known to be fickle. If the graphics card does not have enough memory or does not have the right visuals, PBuffers will not work. If OpenGL does not work, try seeking several frames or restarting Cinelerra.

Limitations:

• OpenGL does not affect rendering. It just accelerates playback.
• X11-OpenGL processes everything in 8 bit color models, although the difference between YUV and RGB is retained.
• OpenGL does not work with frames whose size is larger than 4096x4096.
  Here is what is written in the console when working with large frames:
  BC_Texture::create_texture frame size <frame_width>x<frame_height> bigger than maximum texture 4096x4096.
• The scaling equation set in the preferences window is ignored by OpenGL. OpenGL always uses linear scaling.
• Project and track sizes need to be multiples of four for OpenGL to work.
• To get the most acceleration, OpenGL-enabled effects must be placed after software-only effects. All rendering before the last software-only effect is done in software. The core Cinelerra operations like camera and projector are OpenGL.
• Not all of the effects support OpenGL acceleration. The following effects support OpenGL: Brightness, Chromakey, ChromakeyHSV, Color balance, Deinterlace, Diffkey, Dissolve, Flip, Frames to fields, Freeze frame, Gamma, Gradient, Histogram, Hue saturation, Interpolate Pixels, Invert video, Linear blur, Overlay, Perspective, Radial blur, RGB601, Rotate, Scale, Threshold, Zoomblur.

3.3.5 Buz

This is a method for playing motion JPEG-A files directly to a composite analog signal. It uses a popular hack of the Video4Linux 1 driver from 2000 to decompress JPEG in hardware. Even though analog output is largely obsolete, newer drivers have replaced BUZ.

3.3.6 Raw 1394 video playback

This was the first interface between GNU/Linux software and firewire camcorders. It is the least reliable way to play video to a camcorder and it consists of a library on top of the kernel commands.

3.3.7 DV 1394 video playback

3.3.8 IEC 61883 video playback

3.4 Playback

3.4.1 Audio out
3.4.2 Video out

3.4.1 Audio out

These determine what happens when you play sound from the timeline.

• Playback buffer size
  For playing audio, small fragments of sound are read from disk and processed sequentially in a virtual console. A larger value here causes more latency when you change mixing parameters but yields more reliable playback. Some sound drivers do not allow changing of the console fragment, so latency is unchanged no matter what the value. Previously, a good way of ensuring high quality playback was to read bigger fragments from the disk and break them into smaller fragments for the soundcard. That changed when the virtual console moved from the push model to the pull model. Since different stages of the rendering pipeline can change the rate of the incoming data, it would be difficult to disconnect the size of the console fragments from the size of the fragments read from disk.
• Audio offset
  The ability to tell the exact playback position on GNU/Linux sound drivers is poor, if it is provided at all. Since this information is required for proper video synchronization, it has to be accurate. The audio offset allows users to adjust the position returned by the sound driver in order to reflect reality. The audio offset does not affect the audio playback or rendering at all. It merely changes the synchronization of video playback.

The easiest way to set the audio offset is to create a timeline with one video track and one audio track. Expand the audio track and center the audio pan. The frame rate should be larger than 24 fps and the sampling rate should be greater than 32000. The frame size should be small enough for your computer to render it at the full frame rate. Highlight a region of the timeline starting at 10 seconds and ending at 20 seconds. Drop a gradient effect on the video track and configure it to be clearly visible. Drop a synthesizer effect on the audio and configure it to be clearly audible.
Play the timeline from 0 and watch to see if the gradient effect starts exactly when the audio starts. If it does not, expand the audio track and adjust the nudge. If the audio starts ahead of the video, decrease the nudge value. If the audio starts after the video, increase the nudge value. Once the tracks play back synchronized, copy the nudge value to the audio offset value in preferences.

Note: if you change sound drivers or you change the value of Use software for positioning information, you will need to change the audio offset because different sound drivers are unequally inaccurate.

• View follows playback
  This causes the timeline window to scroll when the playback cursor moves. This can bog down the X Server or cause the timeline window to lock up for long periods of time while drawing the assets.
• Use software for positioning information
  Most soundcards and sound drivers do not give reliable information on the number of samples the card has played. You need this information for synchronization when playing back video. This option causes the sound driver to be ignored and a software timer to be used for synchronization.
• Audio playback in realtime
  Back in the days when 150 MHz was the maximum speed for a personal computer, this setting allowed uninterrupted playback during periods of heavy load. It forces the audio playback to the highest priority in the kernel. Today, it is most useful for achieving very low latency between console tweaks and soundcard output. You must be root to get real-time priority.
• Audio driver
  There are many sound drivers for GNU/Linux. This allows selecting one sound driver and setting parameters specific to it. The sound drivers and their parameters are described in the sound driver section. See section Audio drivers.

3.4.2 Video out

These determine how video gets from the timeline to your eyes.

• Play every frame
  This causes every frame of video to be displayed even if it means that the playback of the video track(s) will fall behind. This option should always be enabled unless you use uncompressed codecs. As of 1/2007, most compressed codecs do not support frame dropping anymore.
• Framerate achieved
  The number of frames per second being displayed during playback. This is updated during playback only.
• Decode frames asynchronously
  If you have lots of memory and more than one CPU, this option can improve playback performance by decoding video on one CPU as fast as possible while dedicating the other CPU to playing back video. It assumes all playback operations are forward and no frames are dropped. Operations involving reverse playback or frame dropping are negatively impacted. Since this option requires enormous amounts of memory, Cinelerra may crash if the input frames are very large.
• Scaling equation
  This algorithm is used when video playback involves any kind of scaling or translation in the virtual console. This does not affect 1:1 playback.
  * Nearest neighbor enlarge and reduce
  • Low quality output with fast playback. Produces jagged edges and uneven motion.
  • Bicubic enlarge and bilinear reduce
    High quality output with slow playback. Bicubic interpolation is used for enlarging, which blurs slightly but does not show stair step artifacts. A bilinear interpolation is used for reduction, which produces very sharp images and reduces noise. Bilinearly reduced images can be sharpened with a sharpen effect with less noise side effects than a normal sized image.
  • Bilinear enlarge and bilinear reduce
    When slight enlargement is needed, a bilinear enlargement looks better than a bicubic enlargement.
• Preload buffer for Quicktime
  The Quicktime/AVI decoder can handle DVD sources better when this is set to around 10000000. This reduces the amount of seeking required. When reading high bitrate sources from a hard drive, this tends to impair performance by slowing down decoding. For normal use this should be 0.
• DVD subtitle to display
  DVD IFO files usually contain subtitle tracks. These must be decoded with the MPEG decoder. Select Enable subtitles to enable subtitle decoding. There are usually multiple subtitle tracks indexed by number and starting from 0. Enter the index number of the subtitle track to be decoded in the "DVD Subtitle to display" text box or use the tumbler to increase the index value. Go to the asset corresponding to the MPEG file in the Resources window and right click. Click on Info. The number of subtitle tracks is shown at the bottom.
• Interpolate CR2 images
  Enables interpolation of CR2 images. Interpolation is required since the raw image in a CR2 file is a Bayer pattern. The interpolation uses dcraw’s built-in interpolation and is very slow. This operation can be disabled and the Interpolate Pixels effect used instead for faster previewing.
• White balance CR2 images
  This enables white balancing for CR2 images if interpolation is also enabled. This is because proper white balancing needs a blending of all 3 primary colors. White balance uses the camera’s matrix which is contained in the CR2 file. Disabling white balancing is useful for operations involving dark frame subtraction. The dark frame and the long exposure need to have the same color matrix. If you disable Interpolate CR2 Images and use the Interpolate Pixels effect, be aware the Interpolate Pixels effect always does both interpolation and white balancing using the camera’s matrix, regardless of the settings in Preferences. Dark frame subtraction needs to be performed before Interpolate Pixels.
• Video driver
  Normally video on the timeline goes to the compositor window during both continuous playback and when the insertion point is repositioned. Instead of sending video to the Compositor window, the video driver can be set to send video to another output device during continuous playback. However, this does not affect where video is routed when the insertion point is repositioned. The video drivers and their parameters are described in the video drivers section. See section Video drivers.

3.5 Recording

The parameters here expedite the File->Record… function by allowing the user to pre-configure the file format. The file format is applied to all recordings. Also set here is the hardware for recording, since the hardware determines the supported file format (in most cases).

3.5.1 File format
3.5.2 Audio in
3.5.3 Video in

3.5.1 File format

This determines the output file format for recordings. It depends heavily on the type of driver used. The menu selections are the same as the rendering interface. See section Rendering files. The Record audio tracks toggle must be enabled to record audio. The Record video tracks toggle must be enabled to record video. The wrench button left of each toggle opens a configuration dialog in order to set the compression scheme (codec) for each audio and video output stream. The audio and video is wrapped in a container format defined by the File Format menu. Different wrappers may record audio only, video only, or both.

Some video drivers can only record to a certain container. DV, for example, can only record to Quicktime with DV as the video compression scheme. If the video driver is changed, the file format may be updated to give the supported output. If you change the file format to an unsupported format, it may not work with the video driver.

3.5.2 Audio in

These determine what happens when you record audio.

• Record driver
  This is used for recording audio in the Record window. It may be configured the same as the Record Driver for video if the audio and video are wrapped in the same stream. Available parameters vary depending on the driver. Note that the drivers are the same as those available in Preferences->Playback. See section Audio drivers.
• Samples to write to disk at a time
  First, audio is read in small fragments from the device. Then, many small fragments are combined into a large fragment before writing to disk. The disk writing process is done in a different thread. The value here determines how large the combination of fragments is for each disk write.
• Sample rate for recording
  Regardless of what the project settings are, the value set here will be the sample rate used for recording. The sample rate should be set to the highest value the audio device supports.

3.5.3 Video in

These determine what happens when you record video.

• Record driver
  This is used for recording video in the Record window. It may be configured the same as the Record Driver for video if the audio and video are wrapped in the same container. Available parameters vary depending on the driver. Note that the drivers available are the as those available in Preferences->Playback. See section Video drivers.
• Frames to record to disk at a time
  Frames are recorded in a pipeline. First, frames are buffered in the device. Then, they are read into a larger buffer for writing to disk. The disk writing is done in a separate thread from the device reading. For certain codecs the disk writing uses multiple processors. The value set here determines how many frames are written to disk at a time.
• Frames to buffer in device
  This is the number of frames to store in the device before reading and determines how much latency there can be in the system before frames are dropped.
• Use software for positioning information
  Video uses audio for synchronization, but most soundcards do not give accurate position information. Selecting this options makes Cinelerra calculate an estimation of audio position in software instead of hardware for synchronization.
• Sync drives automatically
  For high bitrate recording, the disk drives you use may be fast enough to store the data but your operating system may wait several minutes and stall as it writes several minutes of data at a time. This forces the operating system to flush its buffers every second instead of every few minutes to produce slightly better real-time behavior.
• Size of captured frame
  This is the size of the recorded frames in pixels. It is independent of the project frame size because most video devices only record a fixed frame size. If the frame size given here is not supported by the device, Cinelerra may crash.
• Frame rate for recording
  The frame rate recorded is different from the project settings. This sets the recorded frame rate.

3.6 Performance

You will spend most of your time configuring this section. The main focus of the performance section is rendering parameters not available in the rendering dialog.

• Cache items
  To speed up rendering, several assets are kept open simultaneously. This determines how many are kept open. A number too large may exhaust your memory pretty fast and result in a crash. A number too small may result in slow playback as assets need to be reopened more frequently.
• Seconds to preroll renders
  Some effects need a certain amount of time to settle in. Checking this option sets a number of seconds to render without writing to disk before the selected region is rendered. When using the renderfarm, you will sometimes need to preroll to get seemless transitions between the jobs. Every job in a renderfarm is prerolled by this value. This does not affect background rendering, however. Background rendering uses a different preroll value.
• Force single processor use
  Cinelerra tries to use all processors on the system by default, but sometimes you will only want to use one processor, like in a renderfarm client. This forces only one processor to be used. In addition, the operating system usually uses the second processor for disk access. So this option is really a 1.25 processor mode. The value of this parameter is used in renderfarm clients. Force single processor is a preferences option not an EDL parameter.

3.6.1 Background rendering

3.6.1 Background rendering
3.6.2 Renderfarm

Background rendering was originally conceived to allow HDTV effects to be displayed in real-time. Background rendering causes temporary output to be rendered constantly while the timeline is being modified. The temporary output is displayed during playback whenever possible. This is useful for transitions and previewing effects that are too slow to display in real time. If a renderfarm is enabled, the renderfarm is used for background rendering. This gives you the potential for real-time effects if enough network bandwidth and CPU nodes exist.

Background rendering is enabled in the Performance tab of the Preferences window. It has one interactive function Settings menu -> Set background render. This sets the point where background rendering starts up to the position of the insertion point. If any video exists, a red bar appears in the time ruler showing what has been background rendered.

It is often useful to insert an effect or a transition and then select Settings menu -> Set background render right before the effect to preview it in real time and full frame rates.

• Frames per background rendering job
  This only works if a renderfarm is being used; otherwise, background rendering creates a single job for the entire timeline. The number of frames specified here is scaled to the relative CPU speed of rendering nodes and used in a single renderfarm job. The optimum number is 10 - 30 since network bandwidth is used to initialize each job.
• Frames to preroll background
  This is the number of frames to render ahead of each background rendering job. Background rendering is degraded when preroll is used since the jobs are small. When using background rendering, this number is ideally 0. Some effects may require 3 frames of preroll.
• Output for background rendering
  Background rendering generates a sequence of image files in a certain directory. This parameter determines the filename prefix of the image files. It should be on a fast disk, accessible to every node in the renderfarm by the same path. Since hundreds of thousands of image files are usually created, ls commands will not work in the background rendering directory. The browse button for this option normally will not work either, but the configuration button for this option works.
• File format
  The file format for background rendering has to be a sequence of images. The format of the image sequences determines the quality and speed of playback. JPEG is good most of the time.

3.6.2 Renderfarm

To use the renderfarm, set these options. Ignore them for a standalone system

• Use render farm for rendering
  When selected, all the file->render operations use the renderfarm.
• Nodes
  Displays all the nodes on the renderfarm and shows which ones are active. Nodes are added by entering the host name of the node, verifying the value of port and selecting add node. If you have hundreds of nodes, experienced users may be better off editing the ‘~/.cinelerra-cv/.Cinelerra_rc’ file rather than using configuration dialog. Remember that ‘.Cinelerra_rc’ is overwritten whenever a copy of Cinelerra exits. Once nodes are created, select the ON column to activate and deactivate nodes. Nodes may be edited by highlighting a row and hitting apply changes.
• Hostname
  Edit the hostname of an existing node or enter the hostname of a new node here.
• Port
  Edit the port number of an existing node or enter the port number of a new node here.
• Apply changes
  When editing an existing node, select this to commit the changes to hostname and port. The changes will not be committed if you do not click this button.
• Add node
  Create a new node with the hostname and port settings.
• Delete node
  Deletes whatever node is highlighted in the nodes list.
• Sort nodes
  Sorts the nodes list based on the hostname.
• Reset rates
  This sets the framerate for all the nodes to 0. Frame rates are used to scale job sizes based on CPU speed of the node. Frame rates are calculated only when renderfarm is enabled.
• Total jobs to create
  Determines the number of jobs to dispatch to the renderfarm. The more jobs you create, the more finely balanced the renderfarm becomes. You can determine the total jobs to create by multiplying the number of nodes including the master node by some number. Multiply them by 1 to have one job dispatched for every node. Multiply them by 3 to have 3 jobs dispatched for every node. If you have 10 slave nodes and one master node, specify 33 to have a well balanced renderfarm.

3.7 Interface

These parameters affect purely how the user interface works.

• Time format
  Various representations of time are given. Select the most convenient one. The time representation can also be changed by <CTRL> clicking on the timebar. "Ctrl+Left mouse click" selects the next time format. "Ctrl+Middle mouse click" selects the previous time format.
• Index files go here
  Back in the days when 4 MB/sec was extremely fast for a hard drive, index files were introduced to speed up drawing the audio tracks. This option determines where index files are placed on the hard drive.
• Size of index file
  This determines the size of an index file. Larger index sizes allow smaller files to be drawn faster, while slowing down the drawing of large files. Smaller index sizes allow large files to be drawn faster, while slowing down small files.
• Number of index files to keep
  To keep the index directory from becoming unruly, old index files are deleted. This determines the maximum number of index files to keep in the directory.
• Delete existing indexes
  When you change the index size or you want to clean out excess index files, this deletes all the index files.
• Use thumbnails
  The Resource Window displays thumbnails of assets by default. Drawing asset thumbnails can take a while. This option disables thumbnail drawing.
• Dragging edit boundaries does what
  Cinelerra not only allows you to perform editing by dragging edit boundaries, but also defines three separate operations that occur when you drag an edit boundary. Here you can select the behavior of each mouse button. The usage of each editing mode is described in the editing chapter. See section Trimming.
• Min dB for meter
  Some sound sources have a lower noise threshold than others. Everything below the noise threshold is meaningless. This option sets the meters to clip below a certain level. Consumer soundcards usually bottom out at -65. Professional soundcards bottom out at -90. See section Sound level meters window.
• Max dB for meter
  This sets the maximum sound level represented by the sound meters. No matter what this value is, no soundcard can play sound over 0 dB. This value is presented merely to show how far over the limit a sound wave is. See section Sound level meters window.
• Theme
  Cinelerra supports variable themes. Select one here and restart Cinelerra to see it.

3.8 About window

This section gives you information about the copyright, the time of the current build, the lack of a warranty, and the versions of some of the libraries. Be sure to agree to the terms of the lack of the warranty.