TABLE OF CONTENTS ............................................................................................................................. 2
TABLE OF FIGURES ................................................................................................................................. 3
INDEX OF TABLE ...................................................................................................................................... 4
Ring Tones ............................................................................................................................................ 17
S
UPPORTED SOUND FORMATS
MIDI S
MIDI A
MP3 A
Available Sound Properties .................................................................................................................. 27
INDEX ......................................................................................................................................................... 34
Welcome to the Creating Media for the MOTOKRZR K3 guide. This guide contains all the
information you need to get started developing pictures, animation, and sounds for the
MOTOKRZR K3.
The MOTOKRZR K3 Media 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
5
Table 1 shows common terms used in this guide:
Term Definition
AMR Adaptive Multi Rate
GIF Graphics Interchange Format
MIDI Musical Instrument Digital Interface
MIDI Patch One of the channels in a MIDI device, defined by the general MIDI
standard
MPEG Moving Pictures Experts Group
Pixel One picture element on the display
QCIF Quarter Common Intermediate Format
WAP Wireless Application Protocol
Term Definition
WBMP Wireless Bitmap
References
Table 2 shows references providing information related to developing media for the
MOTOKRZR K3:
Organization URL
Table 1 Glossary
3GPP
MIDI Manufacturers Association
Motorola Developer Program
Moving Pictures Experts Group
WAP Forum
World Wide Web Consortium
Open Mobile Alliance
Revision History
Version Date
00.01
01.00
http://www.3gpp.org
http://www.midi.org
http://developer.motorola.com
http://www.chiariglione.org/mpeg/
http://www.wapforum.org
http://www.w3.org
http://www.openmobilealliance.org
Table 2 References
Reason
(DD-MMM-YYYY)
15-JAN-2007 Initial draft.
23-APR-2007 Document Release
Table 3 Revision History
6
Display
This chapter describes the display characteristics for the MOTOKRZR K3.
MOTOKRZR K3
7
Figure 1 Display characteristics for the MOTOKRZR K3
Display Info
The physical internal display characteristics of the MOTOKRZR K3 are the following:
Item Description
Screen resolution
Internal: 320 x 240
External: 160 x 120
Screen dimensions
Active Area 30.6 mm X 40.8 mm
Viewing Area: 32.08 mm X 42.28 mm
Color depth 16 Bits
Internal: 262 K
Maximum colors
External: 65 K
Text area Numeric
Table 4 Display Info
8
Figure 2 The MOTOKRZR K3 display
Note: Screen shot may not reflect actual display size.
Graphics & Video
This chapter describes the graphic environment available in the MOTOKRZR K3. 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. 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 consumer has the ability to download and use a variety of files
to enhance the user experience.
Supported Picture Formats
The MOTOKRZR K3 supports the following graphic and animation formats:
Type Description
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 pictures.
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.
BMP File writing forma, where the information is recorded using
"bitmap".
EMS BMP Enhanced Messaging Service bitmap
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.
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.
9
Type Description
PNG Portable Network Graphics (PNG) format is intended to
provide a portable, legally unencumbered, wellcompressed, well-specified standard for lossless bit
mapped image files.
Table 5 Graphic and animation formats
Note: 'Maximum image sizes are determined by the handset's available memory, however
in Java the use of scalable JPEG will allow larger images to be displayed'.
Table 6 shows the maximum decode size and resolution for supported picture
formats:
Format Maximum Decode Size Resolution
JPEG
PNG
BMP
GIF 87a, 89a
WBMP
EMS BMP
Video Playback
The MOTOKRZR K3 handset supports the video formats described in Table 7:
Type Description
MPEG-4 The MPEG-4 format provides standardized technological
Up to UVGA 1200x1600
pixels (2.0 MegaPixel)
Up to VGA (640 x 480 pixels)
QVGA
(320x240 pixels)
Table 6 Maximum decode size and resolution
elements that enable interactive multimedia (video/audio),
interactive graphics, and digital television.
(320x240 pixels)
QVGA
Codec support includes:
• MPEG
• H.263 Baseline
A maximum of 15 fps for video playback and 15 fps for video
capture is available at a bit rate of up to 64 kbps when maximum
size is QCIF.
H.263 An International Telecommunication Union (ITU) standard for
video compression.
10
Type Description
WMV v9 (also
WMV v7, v8)
WMV - Windows Media Video is a generic name for the set of
streaming video technologies developed. This format also
supports WMV version 7 and 8.
RV8/RV9 Real Video format for Packet and Circuit Switched Streaming
services and clip playback from local files.
A maximum of 15 fps is available at a bit rate of 128 kbps when
the maximum size is QCIF
Table 7 Video formats
Note: Maximum file sizes are determined by the handset’s available memory
Table 8 shows the bit rate, frame size, and frame rate for all supported video playback
formats:
Format Bit Rate (kbps) Frame Size Frame Rate (fps)
MPEG4
H.263
WMV v9 (also WMV
v7, v8)
Up to 256 kbps
Up to 128 kbps
QCIF
25
15
Real Video 8, 9
Table 8 Bit rate, frame size and frame rate video playback suported
Table 9 shows the specifications for all supported audio + video playback formats:
Format
MPEG4 + AMR-NB
MPEG4 + AMR-WB
MPEG4 + AAC
MPEG4 + AAC+
MPEG4 + Enhanced
AAC+
H.263 + AMR-NB
11
Total Bit
Rate
Up to 256
kbps
Size
QCIF
Video Audio
Bit rate
(kbps)
Up to 243
kbps
Up to 232
kbps
Up to 224
kbps
Up to 243
kbps
Frame
Rate
25 fps
Bit Rate
(kbps)
Up to 12.2 kbps
Up to 23.85
kbps
Up to 128 kbps
Up to 12.2 kbps
Sampling Rate
(KHz)
Up to 44.1
8
16
8
Stereo/Mono
Mono
Stereo / Mono
Mono
H.263 + AMR-WB
H.263 + AAC
Up to 232
kbps
Up to 23.85
kbps
16
H.263 + AAC+
H.263 + Enhanced
AAC+
WMV + WMA
Real Audio + Video
Format Bit Rate (kbps) Frame Size Frame Rate (fps) Extension
MPEG4
H.263
WMV v9 (also WMV
v7, v8)
Real Video 9 (also
Real Video 8)
Up to 128
Kbps
Up to 224
kbp
Up to 108
kbps
Up to 96
15 fps
Up to 128 kbps
Up to 96 kbps
Up to 44.1 Stereo / Mono
kbps
Table 9 Graphic and animation formats
Table 10 shows the bit rate, frame size, frame rate, and extension for supported video
streaming formats:
Up to 128
Table 10 Bit rate, frame size and frame rate streaming suported
QCIF
15
.sdp
.rts
Table 11 shows the specifications for video + audio streaming:
Video Audio
Format
MPEG4 / H.263 +
AMR-NB
MPEG4 / H.263 +
AMR-WB
Total Bit
Rate
Size
Bit rate
(kbps)
Frame
Rate
Bit Rate
(kbps)
Up to 115 Up to 12.2 8
Up to 104 Up to 23. 85 16
MPEG4 / H.263 +
AAC
MPEG4 / H.263 +
AAC+
128 Kbps QCIF
Up to 96 Up to 32
15 fps
MPEG4 / H.263 +
Enhanced AAC+
WMV + WMA Up to 112 Up to 48
Real Audio + Video
Table 11 Video + Audio streaming
Up to 96
Up to 32
Sampling Rate
Stereo/Mono
(KHz)
Mono
Up to 44.1 Stereo / Mono
12
Graphics and Video Capture
MPEG4 or H.263
MPEG4 or H.263
Table 12 shows the video quality, bit rates, frame size, frame rate, and maximum
durations for video capture:
Format Video Quality
Bit Rate
(kbps)
Frame Size
Frame
Rate
Low 64
MPEG4 or
H.263
Medium 96
QCIF 15 fps
High 128
Table 12 Maximum durations for video capture
Table 13 shows the video quality, bit rates, frame size, frame rate, and maximum
durations for video + audio capture:
Audio
Sampling
Rate
Stereo/
Mono
Mono1 hour
Video
Bit rate
(kbps)
Up to 115
Up to 104
Frame
Rate
15 fps
Bit Rate
(kbps)
12.2 8 kHz
23.85 16 kHz
Total
Format
+ AMR-NB
Bit Rate
(kbps)
Up to
128
Size
QCIF
+ AMR-WB
Table 13 Maximum durations for video + audio capture
Maximum Capture
Duration
1 hour
Maximum Capture
Duration
Table 14 shows the still image capture resolution and size of the supported formats:
Format Camera Resolution Size (pixels)
Internal
Large (VGA) 640x480 pixels
Medium (QVGA) 320x240 pixels
Small (QQVGA) 160x120 pixels
JPEG
External1
Large (UXGA, 2.0 MPixel) 1200x1600 pixels
Medium (1.2 MPixel) 960x1280 pixels
Small (VGA) 480x640 pixels
X-Small (QVGA) 240x320 pixels
Table 14 Still image capture
1
The MOTOKRZR K3 External Camera is mounted portrait.
13
Bit Rate
Video Telephony
Table 15 shows the specifications for supported circuit-switched video telephony formats:
Total
Format
MPEG4+AMR-NB
MPEG4+ G.723.1
H.263+AMR-NB
H.263+ G.723.1
Note: Total Bit Rate indicates the maximum possible data rate used on the circuitswitched radio access bearer, taking into account the overhead needed by the video
telephony protocols. A total bit rate of 64 kbps allocates 42 kbps to video, 12 kbps to
audio, and 10kbps to protocol overhead.
2
(kbps)
64 QCIF 38 to 42 15 fps Up to 12.2 8 kHz
Size Bit rate (kbps)
Table 15 Supported circuit-switched video telephony formats
MMS/SMS Support
The MOTOKRZR K3 MMS/SMS applications support use of the following image
formats/sizes:
Video Audio
Frame
Bit Rate (kbps) Sampling Rate Stereo/Mono
Rate
Mono
14
• JPEG
• GIF
• BMP
• PNG
The MOTOKRZR K3 supports use of the following audio formats:
• MP3
• MIDI
• AMR-NB, AMR-WB
• AAC
• AAC+
• Enhanced AAC+
• WMA
• XMF
• Real Audio 9,8
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 following image formats are supported for wallpaper:
Technical Specifications for Wallpapers:
Dimensions: Internal: 320 x 240
Colors: Internal: 256 (limited by JPG format)
Recommended File Size: Internal: Up to 100 K
Wallpaper images are displayed on screen as shown in Figure 3.
Wallpaper images appear
behind all screen elements
on the idle screen.
Figure 3 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 4.
15
Wallpaper images appear
behind all screen elements
on the menu screen.
Tiled image used as wallpaper
and appearing behind all screen
elements on an idle screen.
Figure 4 GIF Image as centered 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 3).
•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 animated GIF becomes
the wallpaper image. It’s important that the colors of the wallpaper image allow the text
displayed on the screen to remain legible.
16
This chapter describes the sound environment available in the MOTOKRZR K3. It
includes information on sound formats and more. Use this chapter as a reference when
creating sounds for your products.
In general, file size is limited by available memory. The available 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 carrier 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 experience.
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 MOTOKRZR K3 support the following sound formats:
Type Description
MIDI The MOTOKRZR K3 are MIDI 1.0 compliant (.mid, .midi, .mmf,
.smf), and supports any data format described in The Complete MIDI 1.0 Detailed Specification, including:
− MIDI, Type 0
− MIDI, Type 1
− Scalable Polyphonic MIDI (SP-MIDI)
AAC
Short for Advanced Audio Encoding (.aac, .adcs, .adif), one of the
audio compression formats defined in the MPEG-2 standard. AAC
17
Type Description
boosts higher quality audio reproduction than MP3 and requires
30% less data to do so.
AMR-NB, AMRWB
GSM FULL RATE
MP3
Real Audio
WAV
WMA
XMF
Table 16 Supported audio formats
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.
Format for speech coding used in most GSM networks. The GSM
full rate requires one full rate traffic channel to carry its data. The
compression involves mapping input blocks of 160 speech
samples to encoded blocks of 260 bits.
The MP3 format (.mp3) provides the coding of audio for digital
storage.
Real Audio (.ra, .rm) is a compressed format suitable for streaming
over the internet.
Format for storing files (.wav). Linear pcm 8-bit and 16-bit, CCITT
A-law and U-law.
Windows Media Audio (.wma), referring to components of the more
general Windows Media Format proprietary standard.
Mobile XMF-MIDI: XMF (eXtensible Music Format) is an open
standard file format for gathering together into a single file all
media assets (and/or links to external media assets) required to
render a MIDI note-based piece (or suite of related pieces) in a
computer-based player (or possibly an instrument) with consistent
audio playback across all players and platforms, and suited for
interactivity, content protection, meta-data, and the Internet – and
keep it simple.
Table 17 shows the bit rate, sampling rate, and stereo/mono capabilities for each
supported format:
Format Bit Rate (kbps) Sampling Rate (kHz) Stereo/Mono
4.75 kbps – 12.20 kbps
AMR-NB
AMR – WB
AAC
(MPEG4 AAC-LC)
AAC+ Stereo / Mono
Enhanced AAC+
(supports all 3GPP
specified rates)
6.6 – 23.85 (suports all
3GPP specified rates)
8 kHz
Mono
16
Up to 256 kbps 48 kHz Stereo / Mono
Up to 128 kbps
(16 to 128 kbps)
Up to 48 kHz
(16, 22.05, 24, 32, 44.1,
48 kHz)
Stereo
MP32 Up to 256 kbps 48 kHz Stereo / Mono
8-bit Linear PCM 64 kbps 8 kHz Mono
2
Supports the MP3 coding scheme for the compression of audio signals, as defined in the MPEG-1 and MPEG-2, Part
3 (audio), Layer 3 standard.
18
16-bit Linear PCM 128 kbps
8-bit A-law PCM
8-bit mu-law PCM
GSM Full Rate
64 kbps
12.20 Kbps
WMA v9 L2
(also WMA v3, v7, v8)
Up to 160 Kbps 48 kHz
Real Audio 8
Supports LBR (Cook)
Up to 96 Kbps 44.1 kHz
formats.
5.0 Kbps (fixed rate)
(ACELP®.net)
Table 17 Audio bit rate, sampling rate and stereo/mono capabilities
Table 18 Bit rate, sampling rate, stereo/mono streaming
Sampling Rate
kHz
8 kHz
16 kHz
48 kHz
Up to 48 kHz
(16, 22.05, 24,
32, 44.1, 48 kHz)
48 kHz
8 kHz Real Audio Sipro
Stereo/Mono Extension
Mono
.sdp
.rts
Stereo / Mono
Mono
19
Note: Real Audio 8 supports the Flavor index of 17-26, inclusive. Flavor indexes less than
17(G2) or greater than 26 (surround) are not supported.
MIDI Support
Type 2 (mobile DLS)
The Musical Instrument Digital Interface (MIDI) enables consumers to use multimedia
computers and electronic musical instruments to create, enjoy and learn about music.
The MIDI protocol is a music description language in which 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.
Technical Specifications for MIDI:
Recommended File Size: No limitation. Depends on memory available.
MIDI Instruments: 128 Melodic, 47 Percussion
Maximum Polyphony: 64 voices
Minimum Duration per note: 20ms
Maximum Duration (NW dependent): No limitation on handset. (Network
dependent).
Format File Type
Standard MIDI
Mobile XMF MIDI
MIDI Key Mapping
The MOTOKRZR K3 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
Type 0
Type 1
SP
Type 0
Type 1
Table 19 MIDI Format Specification
Patch Names
0 Acoustic Grand Piano
1 Bright Acoustic Piano
2 Electric Grand Piano
Polyphony
Channels
64 128 Melodic, 47 Percussion
Instruments (Gen. MIDI
Level 1)
Valid MIDI
Note Numbers
21-108
21-108
22-108
20
3 Honky-tonk Piano
4 Electric Piano 1
21-108
21-108
Patch
Number
Patch Names
Valid MIDI
Note Numbers
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
20 Reed Organ
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
24-96
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
36 Slap Bass 1
48-89
48-84
48-89
36-84
36-84
36-86
36-86
36-86
36-96
36-96
36-96
24-72
24-72
24-72
24-72
24-72
21
Patch
Number
Patch Names
Valid MIDI
Note Numbers
37 Slap Bass 2
38 Synth Bass 1
39 Synth Bass 2
40 Violin
41 Viola
42 Cello
43 Contrabass
44 Tremolo Strings
45 Pizzicato Strings
46 Orchestral Harp
47 Timpani
48 String Ensemble 1
49 String Ensemble 2
50 Synth Strings 1
51 Synth Strings 2
52 Choir Aahs
24-72
24-96
24-96
48-96
48-96
36-96
24-96
24-96
24-96
21-103
36-84
24-96
24-96
24-96
24-96
36-96
53 Voice Oohs
54 Synth Voice
55 Orchestra Hit
56 Trumpet
57 Trombone
58 Tuba
59 Muted Trumpet
60 French Horn
61 Brass Section
62 Synth Brass 1
63 Synth Brass 2
64 Soprano Sax
65 Alto Sax
66 Tenor Sax
67 Baritone Sax
68 Oboe
36-96
36-96
36-72
36-96
36-96
24-72
48-84
36-96
24-96
24-96
24-96
48-89
48-84
36-84
24-84
48-96
22
Patch
Number
Patch Names
Valid MIDI
Note Numbers
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)
84 Lead 5 (charang)
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
36-96
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)
100 FX 5 (brightness)
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
36-96
23
Patch
Number
Patch Names
Valid MIDI
Note Numbers
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
116 Tailo Drum
36-96
36-96
36-96
48-77
48-84
48-79
48-96
48-96
36-77
48-96
48-96
60-96
48-72
48-88
48-72
48-72
117 Melodic Drum
118 Synth Drum
119 Reverse Cymbal
120 Guitar Fret Noise
121 Breath Noise
122 Seashore
123 Bird Tweet
124 Telephone Ring
125 Helicopter
126 Applause
127 Gunshot
36-84
36-84
48-72
48-72
48-72
48-72
48-72
48-72
48-72
48-72
48-72
none Drums 35-81
Table 20 MIDI Key Mapping
24
MIDI Audio Guidelines
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 MOTOKRZR K3.
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 events 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 Standard MIDI File (SMF) of type 0 or type 1. In a
type 0 SMF, the file format uses one header chunk with one-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.
25
6. Do not use Copyright Text Fields.
7. Limit the use of continuous controller information such as pitch-bend and volume.
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 the 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 compress 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:
Technical Specifications for MP3:
26
Sample Rates: 48 kHz
Bit Rate: 256 kbps maximum.
Recommended File Size: No limitation. Depends on memory available
Available Sound Properties
Follow technical specifications outlined above.
Design Guidelines
Since ring tones need to be at a consistent 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 0db before saving the compressed MP3 file.
Note 6: 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.
27
Appendix A: DRM
Digital Rights Management
Digital Rights Management (DRM) is a method of protecting content 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 specific 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 encoded files include the following:
• Media Center
• MMS
• Browser
• Email
• KJava
• Address Book
• Drawing Pad
• Camera
• Recorder
• File Manager
• Phone (calling)
• Power Up/Down Animation
• Wallpaper
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
28
Supported DRM Solutions
Two DRM solutions are supported by Motorola handsets. The solutions are the following:
• Forward Locking – Forward locking construct defined by 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 mechanism differs by including
a rights object within the DRM message which governs the consumption of the
content included along with the rights object. A handset that supports Combined
Delivery will support OMA forward locking.
• Separate Delivery – The OMA Separate Delivery mechanism is an extension of
OMA Forward locking. The Separate Delivery mechanism differs by delivering
the content and the rights object separately. The MOTOKRZR K3 supports
retrieving rights via WAP Push and via HTTP response.
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 completed, the download manager will
strip out the media object that is encapsulated within 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’.
29
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
for preview, the handset shall indicate to the content dispatcher that the media object is
‘forward locked’.
• If theuser selects to store the content from the preview: The media shall be
stored in the appropriate file directory and shall 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 while stored in the file system.
Separate Delivery
In MOTOKRZR K3 implementation, for Forward Lock and Combined Delivery content, the
Media objects will be encrypted (AES128) and packaged according to the same
mechanism as Separate delivery, the encryption key is generated randomly and unique to
each content on a phone. Thus the encrypted content can be stored anywhere in the
phone or TransFlash card. A right object will also be created to save the right constraints
and encryption key. The right object is stored in a hidden directory in phone flash memory
which can not be accessed by end user. Thus the mechanism for indicating a ‘forward
locked’ status is to set a special field in right object.
Right Object
Forward Lock files do not have Right Objects associated 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 Object 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.
30
Content downloaded using the OMA Separate Delivery format has been converted from
plaintext format into DRM content format (DCF). This conversion includes symmetric
encryption of the content making the DRM protected content object useless to parties not
having access to the Content Encryption Key (CEK). The CEK is contained within a rights
object which is delivered independently of the DCF(containing the media). The DCF file
can be distributed as much as desired, yet it will remain protected as the rights object
shall be forward-locked. This is the basis for the superdistribution model. Typically, the
DCF object is downloaded using the browser, after which the rights object is separately
delivered to the device using WAP push. Handsets that support Separate Delivery MUST
support OMA combined delivery as well as OMA forward locking.
File Types
DRM solutions apply to all file formats. The OMA DRM solution 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 handled. 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 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.
RFC 2045 [RFC2045] defines the Content-Transfer-Encoding, which specifies how a
specific body part is encoded for transfer by some transfer protocol. Content-TransferEncoding MUST only be used with body parts of DRM message, not with the whole body
of the DRM message. The device MUST support the identity transfer encoding “binary”.
Other nonidentity Content-Transfer-Encodings like “base64” MAY also be supported
A Content-Transfer-Encoding header, as defined in RFC 2045 [RFC2045], MUST be
present in the body part of the DRM message.
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.
Image/ems.predefined.animation
wbmp .wbmp Display,Print image/vnd.wap.wbmp
Png .png Display,Print image/png
aac .mp4 Play audio/mp4
.3ga Play audio/3gpp
aac (mpeg4
aac-lc) aac+
Enhanced
aac+
Play audio/x-midi
Mp3 .mp3 Play audio/mp3
Play audio/x-mp3
Play audio/mpeg3
Play audio/x-mpeg3
wav .wav Play audio/wav
Play audio/x-wav
amr, amr Play audio/amr
amr-nb, amrwb
wma .wma
Play audio/x-ms-wma
xmf, midi .xmf, .midi,
3gp .3gp Play video/3gp
Play video/3gpp
.3ga Play audio/3gpp
mp4 .mp4 Play video/mp4
.mp4
.3ga
.m4a
.mpg4, .3ga Play audio/mp4, audio/3gpp
.asf
.mid
Play audio/mp4
audio/3gpp
audio/m4a
Play audio/x-ms-wma
audio/asf
Play audio/midi, audio/mid, audio/x-mid,
audio/x-midi, audio/mobile-xmf
32
Play audio/mp4
Play video/mp4v-es
mpeg4 .mp4, .3gp Play video/mp4, video/3gpp
Play video/mpeg4
Play video/mp4v-es
rm .rm, .ram, Play video/vnd.rn-realvideo
Play audio/x-pn-realaudio
Play application/vnd.rn-realmeida.
h.263 .mp4, .3gp Play video/mp4, video/3gpp
mpeg4 + amrnb, mpeg4 +
amr-wb
Note : Tone Sequence as defined in JSR-135 is equal 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 cas7e insensitive
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 MOTODEV website
(http://developer.motorola.com).
33
Index
Adaptive Multi Rate, 5
file size, 9, 17
GIF 87a format, 9
GIF 89a format, 9
Graphics Interchange Format, 5
JPEG format, 9
MIDI, 17
MP3 format, 18
MPEG format, 10
MPEG-1 format, 18
Musical Instrument Digital Interface, 5
QCIF format, 5
sound
ring tones, 17
WAP, 5
WBMP format, 9
Wireless Bitmap, 6
34
35
MOTOROLA and the Stylized M Logo are registered in the U.S. Patent & Trademark Office. All other produc t or
service names are the property of their respective owners.