DISPLAY INFO ............................................................................................................................................. 7
VIDEO PLAYBACK ....................................................................................................................................... 9
THEME SUPPORT ....................................................................................................................................... 11
ALERT TONE SUPPORT .............................................................................................................................. 15
Ring Tones............................................................................................................................................ 15
RIGHT OBJECT........................................................................................................................................... 30
Welcome to the Creating Media for the Motorola V550 guide. This guide contains all the
information you need to get started developing pictures, animation, and sounds for the
Motorola V550.
The Motorola V550 guide covers the following areas:
• Display information, including size, color depth, and more
• Graphic support information
• Video support information
• Sound support information
This document assumes you are familiar with creating different media using the
appropriate tools. This guide does not cover the tools required to create media, rather, it
concentrates on the features and technical abilities of the handset when working with
media.
Motorola recommends that if you are not the sole author or creator of the graphics, video,
or sound, you obtain sufficient license rights, including the rights under all patents,
trademarks, trade names, copyrights, and other third party proprietary rights.
Glossary
The following are definitions of common terms used in this guide:
Term Definition
AMR Adaptive Multi Rate
EMS Enhanced Messaging Service
GIF Graphics Interchange Format
iMelody
MIDI Musical Instrument Digital Interface
MIDI Patch One of the channels in a MIDI device, defined by the general MIDI
MPEG Moving Pictures Experts Group
Pixel One picture element on the display
Infrared Data Association (IrDA) standard for the textual
representation of a ring tone.
standard
Page 5
Term Definition
QCIF Quarter Common Intermediate Format
WAP Wireless Application Protocol
WBMP Wireless Bitmap
References
The following references provide information related to developing media for the Motorola
V550:
Organization URL
3GPP
Infrared Data Association
MIDI Manufacturers Association
Motorola Developer Program
Moving Pictures Experts Group
WAP Forum
World Wide Web Consortium
Open Mobile Alliance
This chapter describes the display characteristics for the Motorola V550. The image below
shows the handset.
V550
Page 7
Display Info
The physical internal display characteristic s of the Motorola V550 are the following:
Item Description
Screen resolution 176w x 220h pixels
Screen dimensions 29 x 39 mm viewing area
Pixel pitch .17 mm pitch, square
Color depth 16 bits
Maximum Colors Up to 65535 colors
Text area
Figure 1. The Motorola V550 display.
9 lines (zoom in)
7 lines (Chinese)
7
Page 8
Graphics & Video
This chapter describes the graphic environment available in the Motorola V550. It includes
information on picture and animation formats, size restrictions, pre-defined media, and
more. Use this chapter as a reference when creating pictures or animations that support
your products.
In general, file size is limited by available memory. All media (wallpaper, screensavers,
ring tones, and themes), whether pre-loaded on the device or downloaded by the user,
share the same storage area (total of 4 MB). The available memory for downloaded files
will vary based on the media pre-loaded into the device. This pre-loaded media will vary
from region to region and from carrier to carrier. Motorola recommends keeping all media
files as small as possible to ensure the cons umer has the ability to download and use a
variety of files to enhance the user experienc e.
Supported Picture Formats
The Motorola V550 handset supports the following graphic and animation formats:
Type Description
EMS 5.0 Bitmaps Enhanced Messaging Service bitmap
GIF 87a Graphics Interchange Format, a standard file format for
lossless compression of still images. It is used to display
static images and is the preferred format for pict ures.
GIF 89a The GIF 89a standard is a superset of the GIF 87a
specification. It allows a sequence of GIF images to be
displayed in succession that generates an animation.
JPEG Joint Photography Expert Group standard. JPEG is
designed for compressing either full-color or gray-scale
images of natural, real-world scenes, not line art or
lettering.
WBMP Wireless Bitmap format described in the WAP
specifications. It is an optimized bitmap format intended
for use in portable devices with smaller screens and
limited display capabilities.
Page 9
Note: The maximum picture resolution is 640 x 480 (VGA). Any images with a higher
resolution will not be displayed.
Video Playback
The Motorola V550 handset supports the following video formats:
Type Description
MPEG-4 The MPEG-4 format provides standardized techn ological
elements that enable interactive multimed ia (video/audio),
interactive graphics, and digital television.
Codec support includes:
• MPEG simple profile Level 0
• H.263 Baseline
A maximum of 7 fps is available at a bit rate of 59Kbps when
maximum size is 128x96.
H.263/H.263
(profile 0)
AMR Audio (for
Video Playback
only)
Note: Maximum file sizes are determined by the han dset’s available memory
Video playback layout for the V550 is the following:
An International Telecommunication Union (ITU) standard for
video compression.
Adaptive Multi Rate offers a wide range of data rates. The
philosophy behind AMR is to lower the data rate as the
interference increases to enable better error correction.
A maximum bit rate of 12.2Kbps and a maximum size of 12 sec,
using extensions .mp4 and .3gp.
Size Layout
Sub-QCIF 1 (small) 88x72
Sub QCIF 2 (medium) 128x96
Full QCIF 176x144
Note: Video can only be played back after a download is complete. Streaming video is not
supported.
9
Page 10
Wallpaper Support
Wallpaper images are static images that are shown on both the idle screen and the main
menu screen. Wallpaper images can be tiled or centered as selected by the user;
centered is the default setting.
The recommended format for wallpaper images is a static GIF (GIF87a) file. Other file
types that can be used as wallpaper image are WBMP and EMS 5.0 bitmaps.
Technical Specifications for Wallpapers:
¾ Dimensions: 176 x 220
¾ Colors: Up to 65535
¾ Recommended File Size: up to 15kb
Wallpaper images are displayed on screen as shown below .
Wallpaper image.
(example only)
Figure 2. How wallpaper is displayed on the idle screen and main menu screen.
If the user has selected to tile the wallpaper, the image is tiled starting from the upper left
hand corner of the working area. The image is tiled horizontally and vertically equal to the
display size, as shown in Figure 3.
Wallpaper images appear
behind all screen elements
on the idle screen.
Wallpaper images appear
behind all screen elements
on the menu screen.
Page 11
Tiled image used as wallpaper
Original image
Figure 3. A GIF Image as tiled wallpaper.
The user has the following options for wallpaper:
• Center – the image is resized to fit on the screen while keeping the aspect ratio.
• Fit-to-screen – the image is resized to fill the screen while keeping the original
aspect ratio (refer to Figure 2).
•Tile – if the image is too large, it is resized to fit the display and tiled, if the image
is too small, it tiles as displayed.
If the user selects an animated GIF image, the first frame of the a nimated GIF becomes
the wallpaper image. It’s important that the colors of the wallpaper im age allow the text
displayed on the screen to remain legible.
and appearing behind all screen
elements on an idle screen.
Image set to fill screen.
For more information, refer to “Screensaver Support”.
Theme Support
The Motorola V550 supports themes. A theme is a wallpaper, a screensaver, and a ring
tone combined into a data set that enables users to customize their experience on the
handset. Theme components are grouped together and downloaded to the handset as a
bundle.
NOTE: The filenames used for screensavers, wallpapers, and ring tones used to create a
theme files are limited to 32 characters each (excluding the dot and extension). Longer
filenames are automatically truncated by the Media Manager (while retaining the
extension) when it creates the theme file. Duplicate filen ames are renamed by the phone
to ensure they are unique. However, it is recomm ended you use unique filenames for
each media element.
For more information on creating theme bundles, see the documentation that
accompanies the Media Manager tools.
11
Page 12
NOTE: Some wireless networks limit the maximum size of a The m e download to 100 KB.
Developers are encouraged to keep their themes to this size or less. This size must also
include header information, which ca n be up to 500 bytes in size.
The following table describes the Motorola Them e File (.mtf):
Byte 0 3 4 . . . . . . k
MTF
Header
3
Bytes
K + 1 . . .
File Contents 1
Variable Bytes
Version Number
1 Byte 1 Byte 4
The following definitions apply to the Motorola Theme File (.mtf):
• Number of Fields – Denotes how many component files are inside the MTF file
• File SizeX – Size of file X in bytes. For example, $00000020 equals 32 bytes file size
• Field Label X – Represents what type of component for the current file.
Size
1
Bytes
… File
Size
N
4
Bytes 1 Byte
Field
Label
Filename
1
Variable
UCS
2 Bytes 2 Bytes 1
. . . File Contents 1
Separator ... Field
Label
N
Byte
Variable Bytes
Filename
N
Variable
UCS
2 Bytes 2 Bytes 2 Bytes
Separator Checksum
o 0 – Wallpaper
o 1 – Screensaver
o 2 – Incoming Ringtone
•Filename X – Name of the file in UCS2 format. For example, “abc.def” is represented by $00 $61
$00 $62 $00 $63 $00 $2E $00 $64 $00 $65 $00 $66
• Separator – Used to denture end of current filename X. V alue is $00 $00
• Checksum – Single byte addition from byte 0 to just before the checksum field. The last 2 bytes is
then the checksum. For example, if calculated checksum is $ 1204AB, then the checksum will be
$04AB
•File Contents X – Actual file contents
Icon Specifications
N/A
Page 13
Enhanced Messaging Service (EMS) Support
The Motorola V550 handset supports use of the following animation settings:
Type Description
Small Color, 8 x 8 pixels (32 bytes = 256 bits)
Large Color, 16 x 16 pixels (128 bytes = 1024 bits)
Frames 4 frames maximum (EMS animations only)
Rate 500 ms
Loop Continuous
The Motorola V550 handset supports use of the following picture settings:
Type Description
Small 16 x 16 pixels (32 bytes = 256 bits)
Large 32 x 32 pixels (128 bytes = 1024 bits)
Variable Size 255 x 255 pixels maximum
Note: All pictures will be in .bmp format and can be received in black and white, 2-bit grey
scale, and 6-bit color.
The Motorola V550 supports use of the following audio settings:
Type Description
Predefined Supported as per the EMS standard
User-defined iMelody format (max size 128 bytes)
Note: EMS messages can support up to 3Kb of inserted o bjects and 450 characters when
sending a message.
Screensaver Support
The Motorola V550 supports screensavers. Screensavers are animated or static images
selected by the user that are shown full screen when the phone has been inactive for a
period of time.
The recommended format for a screen saver is animated GIF (GIF 89a). Other file types
also supported are the following: static GIF (GIF 87a), WBMP, and EMS 5.0 bitmaps.
13
Page 14
Technical Specifications for Screen Savers:
¾ Dimensions: 176 x 220
¾ Recommended Number of Frames: 9-15
¾ Colors: Up to 65535
¾ Recommended File Size: up to 90kb
Screen savers are displayed using the entire screen. In the event an image is larger or
smaller than the display, the following rul es apply:
• Image too small – image is shown at actual size an d centered on display.
• Image too large – image is resized to fill the display while keeping the original aspect
ratio.
Image scaled to fit on the
display while maintaining the
Original Image
original aspect ratio.
Figure 4. How large screensaver images are displayed on the screen
Note: By default, bars may appear on the left/right or top/bottom of the image to fill the
display
If the screensaver is an animation, it plays for one minute and then halts at the first
animation frame. This first frame, or key frame, then remains on the screen. Pl ease note
when creating the animation, the first frame must be a key frame.
Image scaled to fill the
display while maintaining
the original aspect ratio.
Page 15
This chapter describes the sound environment av ailable in the Motorola V550. It includes
information on sound formats and more. Use this ch apter as a reference when creating
sounds for your products.
In general, file size is limited by available memory. The av ailable memory for downloaded
files will vary based on the media that is pre-loaded into the device. This pre-loaded
media will vary from region to region and from carri er to carrier. We recommend keeping
all media files as small as possible to ensure the consumer has the ability to download
and use a variety of files to enhance the user ex perience.
Alert Tone Support
Downloaded audio files can be applied to a number of alert tones on the device including
Ringtones for incoming calls, Text Message, and Date Book Alarms.
Sound
Ring Tones
Ring tones should not exceed 30 seconds because most voice mail systems pick up after
four rings (16-25 seconds depending on the system).
Supported Sound Formats
The Motorola V550 supports the following sound formats:
Type Description
iMelody iMelody is the Infrared Data Association (IrDA) standard for
the textual representation of a ring tone that can be used to
transfer melodies between devices.
MIDI The Motorola V550 are MIDI 1.0 compliant, and supports
15
Page 16
Type Description
MP3
MIDI Support
The Musical Instrument Digital Interface (MIDI) enables consu m ers to use multimedia
computers and electronic musical instruments to create, enjoy and learn about music.
The MIDI protocol is a music description language in w hich every word describes an
action of musical performance. Each action is stored as a binary word and when
combined, store as MIDI files. These files can then be replayed by any electronic device
that can read the MIDI file and recreate the performance using its available sound system.
any data format described in The Complete MIDI 1.0 Detailed Specification, including:
− MIDI, Type 0
− MIDI, Type 1
Scalable Polyphonic MIDI (SP-MIDI)
The MP3 format provides the coding of audio for digital
storage.
Technical Specifications for MIDI:
¾ Recommended File Size: up to 15k
¾ MIDI Instruments: 128
¾ Maximum Polyphony: 24 voices
¾ Minimum Duration per note: 20ms
¾ Maximum Duration (NW dependent): 16-30 secs
MIDI Key Mapping
The Motorola V550 supports all 128 general MIDI instruments and the standard drum kit,
but due to frequency limitations, not all MIDI notes are supported for all patches.
Patch
Number
0 Acoustic Grand Piano
1 Bright Acoustic Piano
2 Electric Grand Piano
Patch Names
Valid MIDI
Note Numbers
21-108
21-108
22-108
3 Honky-tonk Piano
21-108
Page 17
Patch
Number
Patch Names
Valid MIDI
Note Numbers
4 Electric Piano 1
5 Electric Piano 2
6 Harpsichord
7 Clavinet
8 Celesta
9 Glockenspiel
10 Music Box
11 Vibraphone
12 Marimba
13 Xylophone
14 Tubular Bells
15 Dulcimer
16 Drawbar Organ
17 Percussive Organ
18 Rock Organ
19 Church Organ
21-108
24-103
24-89
24-96
48-108
65-108
48-84
48-96
48-97
48-108
48-96
48-96
24-96
24-96
24-96
21-96
20 Reed Organ
21 Accordion
22 Harmonica
23 Tango Accordion
24 Acoustic Guitar (nylon)
25 Acoustic Guitar (steel)
26 Electric Guitar (jazz)
27 Electric Guitar (clean)
28 Electric Guitar (muted)
29 Overdriven Guitar
30 Distortion Guitar
31 Guitar Harmonics
32 Acoustic Bass
33 Electric Bass (finger)
34 Electric Bass (pick)
35 Fretless Bass
68 Oboe
69 English Horn
70 Bassoon
71 Clarinet
72 Piccolo
73 Flute
74 Recorder
75 Pan Flute
76 Blown Bottle
77 Shakuhachi
78 Whistle
79 Ocarina
80 Lead 1 (square)
81 Lead 2 (sawtooth)
82 Lead 3 (calliope)
83 Lead 4 (chiff)
48-96
48-96
24-84
48-96
60-108
48-96
60-96
48-96
48-96
48-96
48-91
60-96
24-96
24-96
36-96
36-96
84 Lead 5 (charang)
85 Lead 6 (voice)
86 Lead 7 (fifths)
87 Lead 8 (bass+lead
88 Pad 1 (new age)
89 Pad 2 (warm)
90 Pad 3 (polysynth)
91 Pad 4 (choir)
92 Pad 5 (bowed)
93 Pad 6 (metallic)
94 Pad 7 (halo)
95 Pad 8 (sweep)
96 FX 1 (rain)
97 FX 2 (soundtrack)
98 FX 3 (crystal)
99 FX 4 (atmosphere)
36-96
36-96
36-96
24-96
36-96
36-96
36-96
36-96
36-96
36-96
36-96
36-96
36-96
36-96
36-108
36-96
19
Page 20
Patch
Number
Patch Names
Valid MIDI
Note Numbers
100 FX 5 (brightness)
101 FX 6 (goblins)
102 FX 7 (echoes)
103 FX 8 (sci-fi)
104 Sitar
105 Banjo
106 Shamisen
107 Koto
108 Kalimba
109 Bagpipe
110 Fiddle
111 Shanai
112 Tinkle Bell
113 Agogo
114 Steel Drums
115 Woodblock
The following are suggested guidelines to maximize sound quality while reducing the
overall file size of a MIDI Ring Tone file for use with the Motorola V550.
Tip 1: Use MIDI’s running status feature
In the MIDI standard, a key-on or a key-off event will use, at most, three bytes each.
However, when several key events occur on the same MIDI-channel, the running status
feature can be used. In principle, running status means the first byte of a key-on event is
omitted. In addition, the key-on event having a velocity of zero is equivalent to the key-off
event. Thus, combining running status with key-on eve nts that have zero velocity reduces
the number of bytes needed to encode all key events.
EXAMPLE:
Without using the running status, features , the sequence
91 2E 23 8E, 91 2B 50 8E, 81 2E 64 00, 81 2B 64 00
represents “Key 2E ON” Velocity 23 MIDI Ch 1”, “Key 2B ON Velocity 50 MIDI Ch 1”,
“Key 2E OFF Velocity 64 MIDI Ch 1”, “Key 2B OFF Velocity 64 MIDI Ch 1”. Using the
running status feature reduces the sequence to:
91 2E 23 8E, 2B 50 8E, 2E 00 00, 2B 00 00,
That is, the command byte is omitted and velocity zero is used for key off.
Tip 2: Use Standard MIDI File (SMF) type 1
The MIDI content can be stored in a Stand ard MIDI File (SMF) of type 0 or type 1. In a
type 0 SMF, the file format uses one header chunk with on e-track chunk. In a type 1 SMF,
the format uses one header chunk with several track chunks. SMF type 2 should not be
used.
In general, it is more efficient to store the MIDI data as a type 1 file. The increased
efficiency is achieved because each track contains only one MIDI channel and one
instrument (often the case). The running status feature can be applied on each individual
track, thereby reducing the track size. To reduce the size of the file even further, use one
track per used MIDI channel. That is, if a temple/conductor track exists, merge it with the
first instrument track and remove all unnecessary meta-events such as the “track name”
and “lyric” meta-events.
To summarize, the following measures can be taken in order to reduce the SMF:
1. Use SMF type 1 (Or verify that a type 1 file is smaller than a type 0 file and use the
smallest file).
2. Use running status.
3. One and only one instrument per track. Try not to change channels.
4. Do not change tempo in the middle of the music. That is, set the tempo once.
5. Use beat, instead of SMPTE, to set the tempo.
6. Do not use Copyright Text Fields.
7. Limit the use of continuous controller information such as pitch-bend and volume.
21
Page 22
8. Turn off the options below:
• Sequence Number - MIDI sequence ids
• Text - embedded text for any optional fields
• Sequence / Track Name
• Instrument Name
• Lyric
• Marker - for synchronization purposes
• Cue Point
• Midi Channel Presix - associate channels with all events following
• Sequencer-Specific settings
Items one through three above optimize the encoding of the notes, while items four to
eight optimize the overall melody. The above measures provide an SMF file that is readymade for compression. However, prior to compression, the composer/content author can
add a few values for key velocity, thereby increasing the redundancy of the file.
Tip 3: Consider the Frequency Response
Even though the MIDI synthesizer is sampled at 22 KHz, the polyphonic speaker’s
frequency response is not as wide. Try to keep th e majority of melodic information below
6000 Hz.
NOTE: The use of MIDI notes below 800 Hz may cause a decrease in volume when
playing the note. Always test your audio on an actual device to ensure the accuracy of the
sound you want to produce.
MP3 Audio Guidelines
MP3 (MPEG Audio Layer 3) is an audio compression technology that is part of the MPEG1 and MPEG-2 specifications. Developed in Germany in 1991 by the Fraunhofer Institute,
MP3 uses perceptual audio coding to c ompress CD-quality sound by a factor of 12, while
providing almost the same fidelity. Because MP3 audio is digitized, not synthesized,
reproduction (disregarding speaker quality) is identical on all devices. Therefore MP3 ring
tones provide a near-CD quality audio experience for listeners as opposed to their MIDI
counterparts which differ greatly from device to device.
The following recommendations should be used when designing MP3 audio clips for use
in the phone:
Page 23
Technical Specifications for MP3:
¾ Bit Rate: 65kbps max
¾ Recommended File Size: 100K
¾ Maximum Duration (NW dependent): 16-30 secs
Available Sound Properties
The following table describes the available MP3 encoding properties on the V550.
*Overall bit-rate cannot exceed 64 kbps. Any MP3s encoded higher than 64 kbps will not
play on the device.
Note: There is no stereo speaker support for the Motorola V550. Stereo ring tones will be
played in mono. If the handset supports a stereo file and a stereo headset is attached, the
file will be played in stereo.
Depending of frequency content of the material the recommended properties for MP3 ring
tones are:
MP3 44.1kHz 16 Mono 64
MP3 24kHz 16 Mono 40
Design Guidelines
Since ring tones need to be at a consist ent audible level, compressing the original content
to reduce the peak-to-average ratio is necessary. After the audio is compressed it is
advisable to re-normalize the audio to 0 db before saving the compressed MP3 file.
Note: Ring tones are generally between 15-20 seconds in length. Based on the
recommended bit rates that would yield a file size between 75-150K per tone. It is
advisable to keep file size beneath 100K to allow the end-user to download multiple tones,
but there is no file size limit except for total free memory available on the device.
23
Page 24
MotoMixer
The Motorola MotoMixer feature allows users to mix a repeating “base track” directly on
the Motorola V550 using the MotoMixer application. The base track consists of four parts:
three content-specified instruments and a drum. Four variations are provided for each part
in the base track file. Selecting one of the four variations for each of the parts at a specific
point in time creates the mix. The mix created by the user can be saved in a file referred
to as the “mix file” and can be recalled later to be used as a ringtone or sent to another
mobile phone using SMS or email.
The four variations defined for each p art are referred to as “Variation A,” Variation B,”
Variation A with effect,” and “Variation B with effect.” The user interface for the MotoMixer
editor allows the user to modify three settings for each part: instrument on/off, which
enables or disables the part entirely; variatio n A/B, which selects the variation played; and
effect on/off, which enables and disables the effect. There are five valid combinations of
these three settings: part turned off (muted) and the four variations listed at the beginning
of this paragraph. The MotoMixer editor starts with all f our parts muted as shown below.
Changes made to the mix by the user will take effect only on 16
base track was written in 4/4 time (four quarter notes per measure), there would be 16
equally-spaced “sequence p oints” in the measure where changes by the user would take
effect.
When played, the base track file is looped. Initial revisions of the Mot oMixer feature will
loop the base track four times. Future revisions may allow t he number of loops to be
configurable (with a default value of four) by the user on a per-mix file basis.
Base Track File Format
MotoMixer base tracks are required to be standard MIDI files stored in format 0 (i.e. data
for all channels is stored in a single track). Base track files can be any length and be
written any time and any key signature. MotoMixer base tracks should be saved with a
.bas file extension.
Channels
The four variations for each part in the base track file are stored as separate channels.
The mapping between part and variation and channel number is shown in the table below.
th
note boundaries. If a
Page 25
Part
Variation
MIDI Channel
Instrument 1
Instrument 2
Drums
Instrument 3
Variation A 1
Variation B 2
Variation A with effect 3
Variation B with effect 4
Variation A 5
Variation B 6
Variation A with effect 7
Variation B with effect 8
Variation A 9
Variation B 10
Variation A with effect 11
Variation B with effect 12
Variation A 13
Variation B 14
Variation A with effect 15
Variation B with effect 16
Instruments
The MotoMixer feature supports use of all 128 General MIDI instruments. Please note that
not all phones are able to distinctly represent all of these instruments (e.g. all General
MIDI piano-like instruments may be represented by a single piano sound – Acoustic
Grand Piano may sound like Electric Piano 2). The Motorola V550 supports the full
instrument set with very limited re-mapping. The General MIDI Percussion Map will be
used for the drum part, so no instrument should be specifie d for the variations of the drum
part.
In the MotoMixer editor, the parts are named by the General MIDI in strument used by the
first note of the “Variation A” variation of the part. That is, if the first note in “Variation A”
for a part is played with the “Whistle” instrument, the part is labeled in the user interface
as “Whistle”. The different variations for a part can be impl emented using different
General MIDI instruments, but the part name displayed to the user will never change. The
drum part will always be named “Drums” regardless of the drum sounds used in the part.
The results of changing instrument mapping for a variation in the middle of the variation
are unpredictable and should be avoided.
25
Page 26
Tempo
Base tracks may use up to four different drum instruments from the General MIDI
Percussion Map. For example, a base track may decid e to use drum instruments 36, 40,
42, and 45 (Bass Drum 1, Electric Snare, Closed Hi Hat, and Low Tom). No additional
drum instruments can be used. If other drum instruments are us ed, only the first four that
are specified in the base track will be heard. This applies across all variations of the drum
part – only the four selected drum instruments can be used in the entire base track.
The tempo of the base track must be specified at a time 0 of the base track file. Tempo is
specified in microseconds per quarter note in a standard MIDI “Set Tempo” meta-event. If
the tempo is not set in the MIDI file, or is not set at time 0, the tempo will default to
500,000 microseconds per quarter note (120 beats per minute). Tempo changes in the
middle of the base track file will be ignored.
The MotoMixer user interface provides the us er with an option to adjust the tempo of the
base track. This user-specified tempo is saved as part of the mix file. The user is allowed
to adjust the tempo on a scale of 0-7. Setting 3 is the default value and will be equal to the
tempo specified in the base track file. Setting 0 is approximately equal to half of the
default temp. Setting 7 is more than double the def ault tempo.
Restrictions
The implementation of the MotoMixer feature uses a MIDI Text Event containing the text
“\!” (backslash exclamation mark) in the form:
FF 01 02 5C 21
Base tracks will not contain text events matching this format. Text events that contain
other text can be included at any point in the base track file.
In addition, files should be created to allow for a maximum polyphony of 16 simultaneous
notes when all tracks and effects are active.
Design Recommendations
Individual instruments’ variations should be varied greatly to allow for an easily
discernable difference between variation 1 and 2. This can be accomplished by using
different rhythmic, harmonic, and melodic structures. One possible recommendation is to
use a more basic structure for variation 1 and a more complex one for variation two
(steady rhythm vs. syncopation). There must be an easily recognizable differentiation
between each of the variations.
With regards to variations with effect, these tracks can be used in a multitude of ways.
One possibility is to use the effect track to add harmony to a melody of an associated
track. Additionally, the effect track can be used to add musical substance such as
arpeggiations or figured basses. Lastly, the effect track can be used to add delay effects
such as echo by copying all musical events a nd pasting them at a short (1/32) offset.
Page 27
Overall, the effect track should be used to add rhythmic, harmonic, or a coustical depth to
the associated variation track.
27
Page 28
Appendix A: DRM
Digital Rights Management
Digital Rights Management (DRM) is a method of protecting c ontent from illegal
distribution by embedding the content into an encrypted package along with rules dictating
its use. Using a set of keys and a license for the sp ecific file, a DRM application is
required to decrypt the content for playback. The DRM application will be transparent to
the user except for the cases where the user acquires a file without a proper license.
Applications that will interact with DRM encode d files include the following:
• Media Center
• MMS
• EMS
• Browser
• Email
• KJava
For more information, refer to the following references found at
http://www.openmobilealliance.org :
• OMA-Download-DRM-v1_0-20020905-C
• OMA-Download-DRMREL-v1_0-20030801-C
• OMA-Download-DRMCF-v1_0-20030801-C
Supported DRM Solutions
Two DRM solutions are supported by Motorola handsets. The solutions are the following:
• Forward Locking – Forward locking construct defined b y the OMA DRM
specification. Similar to NDIS implementation in MMS/EMS.
• Combined Delivery – The OMA Combined Delivery mechanism is an extension
of OMA forward locking. The Combined Delivery m echanism differs by including
a rights object within the DRM message which govern the consumption of the
Page 29
content included along with the rights object. A ha ndset that supports Combined
Delivery will support OMA forward locking.
Download
Forward Lock files will be downloaded within a DRM message. The download manager
will recognize the DRM message of MIME type ‘application/ vnd.oma.drm.message’ as a
valid file type.
The download manager will discard any DRM message that contains more than one
media object within the DRM message.
OMA Combined Delivery will be downloaded within a DRM message and will consist of a
media object and a rights object. The download manager will recognize the DRM
message MIME type and the MIME type ‘application/vnd.oma.drm.rights+xml’ as a valid
file type. A single media object in the body of the DRM message, that is encoded in the
following identity transfer encoding ‘7bit’, ‘8 bit’, and ‘binary,’ will be accepted by the
download manager.
Installation
Forward Lock
After the download of a DRM message has been comp leted, the download manager will
strip out the media object that is encapsulated wit hin the DRM message prior to
dispatching the object for preview. The MIME type associated with the encapsulated
media object will be used to verify that the OMA download descriptor ‘type’ meta data field
matches the MIME type of the media object within the DRM message.
Once the media object has been extracted from the DRM message, the original DRM
message can be discarded. Along with passing the media object to the content dispatcher
for preview, the download manager shall indicate to the content dispatcher that the media
object is ‘forward locked’.
The mechanism for indicating a ‘forward locked’ status is to set the NDIS bit for the file
within the file system.
Combined Delivery
After the download of a DRM message has been completed, the handset will strip out the
media object and the rights object that are encapsulated within the DRM message prior to
dispatching the object for preview. If the DRM message is received without a descriptor
file, the MIME type associated with the encapsulated media object should be used to
verify that the OMA download descriptor ‘type’ meta data field matches the MIME type of
the media object within the DRM message.
Once the media object has been extracted from the DRM message, the original DRM
message can be discarded. Along with passing the media object to the content dispatcher
29
Page 30
for preview, the handset shall indicate to the content dispatcher that the media object is
‘forward locked’.
• If the user selects to store the content from the preview: The medi a shall be
Right Object
Forward Lock files do not have Right Objects associate d with the content. The user has
unlimited usage. The handset will mark the file as "do not forward" and the user will be
able to consume the content as a normal file. The only limitation is the handset will not
allow the user to send the file via any transfer method.
In the case of Combined Delivery there is a Right Ob ject associated with the content. The
Right Object will be stored in a secure area and the user will not have access to it. The
handset will not allow the user to send it via any delivery method. The Right Object will
define the constraints for content usage. This Right Object can have count, time, date, or
interval constraints. The application will check the Right Object before consuming the
content.
stored in the appropriate file directory and s hall be marked as ‘forward-locked’
using the NDIS bit. The rights object shall be stored in a protected portion of the
file system. Rights objects are NEVER to be forwarded. Association between the
rights object and the media MUST be maintained wh ile stored in the file system.
File Types
DRM solutions apply to all file formats. The OMA DRM soluti on is content agnostic and
can be used for any type of content that the handset supports. Individual files are handled
in the same manner as a DRM file would be ha ndled. Files downloaded using OMA
Combined Delivery will be downloaded within a DRM message and will consist of a media
object and a rights object. The download mana ger will recognize the DRM message
MIME type and the MIME type ‘application/vnd.oma.drm.rights+xml’ as a valid file type. A
single media object in the body of the DRM messag e that is encoded in the following
identity transfer encoding ‘7bit’, ‘8 bit’, and ‘binary’ will be accepted by the download
manager.
Page 31
Appendix B: MIME Types
This appendix provides a list of common MIME types used on various Motorola handsets.
The list is sorted by category and provides file type descriptions, as well as the MIME
types used to download different media files.
NOTE: The file and MIME types shown below are not supported by all Motorola handsets.
Please refer to the handset’s media guide to determine what file types a particular
handset supports.
Note: Tone Sequence as defined in JSR-135 is equa l to the following: audio/x-tone-seq
Different strings in the same group are synonyms and are equally applicable for the
corresponding media type.
Please note the following when mapping MIME types to a server:
• A MIME type can be mapped to zero or more file extensions
• Extension mapping is case insensitiv e
For information on configuring servers to deploy programs or files over-the-air, or to
determine which MIME types are supported by a particular handset, download the Basic Over-the-Air Server Configuration whitepaper from the Motocoder website
(http://www.motocoder.com
).
Page 33
Index
Adaptive Multi Rate, 4, 9
AMR format, 9
animation
sizes, 13
EMS format, 8
Enhanced Messaging Service, 4
file size, 8, 15
GIF 87a format, 8
GIF 89a format, 8
Graphics Interchange Format, 4
iMelody, 15
Infrared Data Association, 4
JPEG format, 8
MIDI, 15
MP3 format, 16
MPEG format, 9
MPEG-1 format, 16
Musical Instrument Digital Interface, 4
QCIF format, 5, 9
sound
ring tones, 15
themes, 11
WAP, 5
WBMP format, 8
Wireless Bitmap, 5
MOTOROLA and the Stylized M Logo are registered in the U.S. Patent &
Trademark Office. All other product or service names are the property of their
respective owners.