Scroll to Main content, Navigation
Sprint

Note: This site was designed with Cascading Stylesheets for layout & design. You are seeing this note either because those Stylesheets didn't reach your machine or because you are using an outdated browser. You may only view the raw textual content of this site. In order to view, use, and enjoy this site to the fullest at the maximum security level, please visit our Browser Upgrade page to view a list of browsers that support web standards.


Advanced Search



Design Guidelines

 

This QCELP file was created from a 128kbps 44.1kHz stereo MP3 file that was converted to a 8kHz 16-bit PCM mono WAV file and then converted to the QCELP format using the QCELP SDK.

 

Design Guidelines

 

PNG & JPEG Design Guidelines

  • Do not use interlacing format for any screensaver images. This requirement was created in response to the fact that certain devices do not handle screensaver images with interlacing format.
  • Use 8-bit (256) color depth for all images unless there are specific reasons.  24 bit can be used for higer-end devices that support it (such as the TreoTM 650 by palmOneTM) as long as the files remain under 128K.  If they can not be kept under that limit, use 16 bit.  
  • Size the images to closely match the actual screen size of each device (or device family).  See Device Specifications for screen dimensions.
  • Keep images simple, as the screen size is small and details can be lost or cause a loss of clarity for the overall image.
  • For images with attaches logos, trademarks, or other brand markings, please review the Screen Saver Overlay Zones section.
  • When using images from photograph sources, avoid images with many small objects.  Images that are "close-up" pictures of one object or view only a few objects at a time almost always look better than a cluttered collection of objects. 
  • Use high-contrasting colors whenever available.  This helps define the objects within the image and prevent objects from blending with the background or other objects.
  • Use simple block typography in text graphics (example: "Sprint Rules!").  Do not use a thin cursive font or calligraphy which is hard to read.

 

MIDI Design Guidelines

  • Use standard 16-voice 128 instrument wave-table recording methods for CMX 2.x devices.  For CMX 3.0 devices, the option is also available to use a 32-voice polyphonic format.  For CMX 4.0 devices, the wave table is increased to 48 voices.  We are currently keeping the files at the lowest common denominator for simplicity's sake, and severely limiting the use of midi going forward. This may change later to allow for robust use of instrumentation within CMX, game sounds, etc.
  • Keep the length of the MIDI file and MP3 preview file between 15 20 seconds in length.  
  • Start the first few bars of the MIDI track with easily-recognizable melodies, as this is what is first heard when the phone rings.
  • Avoid melodies that have excessive low-frequency sounds (low tones, percussion instruments), as these do not playback well over a device speaker.  The frequency range for a mobile phone does not sustain high volume of low frequencies over a relatively short distance.

 

QCELP & ADPCM Design Guidelines

  • Use the Qualcomm Pure Voice / QCELP Converter Tool:

http://www.cdmatech.com/solutions/products/purevoice_download.jsp

  • Voice and music samples sound the best on playback through the device speaker.
  • Ensure the recorded sample is using maximum amplitude or volume.
  • Do not exceed the maximum file-size for these files (we must keep to the smallest device size for consistency, which is 64K).
  • Keep the length of the QCELP / ADPCM file and MP3 preview file similar in length (max 25 seconds).  ADPCM has to be max 15 seconds, of the file will end up being to large, and must be 16 bit to ensure good quality. (32 bit is too large, and for songs that do not sound well using ADPCM, bumping up the bit rate makes no difference). We are currently using QCELP exclusively, but this may change later on, at least for some content.
  • Sound effects that use higher-frequencies sound much clearer through the device speaker than low-frequency sounds.  Sound effects that use low-frequencies generally playback poorly and are not recommended.
  • For shorter sounds (approx. 7 sec.), you can include a short time of silence at the end of the sound to have a brief pause as the sound is repeated when used as a ringtone. Shorter length sounds or tones can be used (< 7 sec.), but will be evaluated on a case by case basis (an example would be a popular game show or game tune).
  • Review the "readme.txt" document in the SDK Zip file, as it contains details on the four encoding levels for QCELP files and other information.
  • Volume levels within QCELP files can be a problem if the source WAV files are not loud enough.  There are no volume controls in the QCELP SDK that can change the playback volume of a QCELP file.  The volume is dependent upon the source WAV file, which provides the ability to manipulate the volume levels.  Therefore, the volume levels in the source WAV file should range from -15db to 0db to sufficiently play back QCELP files on a mobile phone at acceptable volume levels.
  • Any filtering of noise has to be done at the source. Filtering out excessive noise from singing into the microphone, instrument distortion, etc, as well as ensuring the volume is high enough will ensure a cleaner QCELP file.

Sample WAV and QCELP files:

Sample QCELP File Sample Wav File QCELP Player

 

                                                       

          AAC+ Design Guidelines

With the release of Qualcomm's 6100 chipset, this next generation of devices are able to use AAC+ file format for ringtones.  There are several requirements in using the AAC audio format to achieve the best quality with the most compact file size on a mobile phone:

  • Audio Codec:  Advanced Audio Codec Plus (AAC+)
  • Audio Profile:  MPEG-4 Main, L2 AAC LC (Low Complexity) Profile (HE-High Efficiency)
  • Audio Bit Rate:  48 kbps max. 32 kbps minimum. 
  • Sample Rate:  48 kHz or 44.1 kHz, stereo max.
  • Clip Length:  the ringer file should be 22 seconds or less - minimum 7 seconds (this can be waived by marketing for certain types of content - do not loop a smaller edits to attain 7 seconds or more).  This looping will occur anyway, just leave the smaller edit and explain to Marketing why it needs to be smaller than 7 seconds.
  • File Size:  the ringer file should be 200 KB or less.
  • File Extension:  the filename extension must be ".m4a".
  • Preview Files: Shockwave Flash files must be used for preview files going forward.  Detailed parameters will be made available next week.  Ensure it is the same quality as submitted AAC+ files.

A list of tools that can be used to create AAC+ content:

  • Coding Technologies, aacPlus Content Creation Package
  • Orban, Opticodec PC Mobile Encoder
  • Nextreaming, Xenon 2 Pro
  • McubeWorks, jun@mcubeworks.com
  • Real Networks, Helix Mobile Producer (upcoming)
  • Nero 6.6 Ultra Edition Ahead Software
  • Winamp (upcoming)

 

 Video Ringers Design Guidelines

Video ringers are movie files that are permanently downloaded to the phone (i.e. non-streaming) and are used by the phone just like any other ringer type.  These are the specific requirements for creating video ringer files:

 

  • Pixel Dimensions: 176W x 144H (i.e. QCIF) - This is a hard-line requirement for all Multimedia devices currently.  Any deviation will be annotated specifiecallly by the device within the device specifications below.
  • Recommended Video Codec: MPEG-4 (Mp4/3GP-3GPP and 3G2 can also be used)
  • Recommended Audio Codec: AAC (16-32 KHz mono channel or 16-22kHz stereo greatly depends on play length) or AAC+ (44.1 KHz Mono or 22 KHz Stereo-this may change as encoding Mp4 with AAC+ is not yet widely supported, and higher sample rates may be possible with this technology.)
  • Video Bit Rate: minimum 32 kbps (recommended bit rate), maximum 48-96 kbps (this depends greatly on play length, and the 256K minimum must still be met)
  • Audio Bit Rate: minimum 24 kbps, maximum 32 kbps - we recommended increasing video quality over audio as long  as minimum audio quality is achieved (Recommended if possible - this depends greatly on play length)
  • Audio Sample Rate: minimum 16 KHz, maximum 48 KHz 
  • Combined Bit Rate:  maximum 128 kbps (this will depend greatly on play length, and 256K minimum must still be met)
  • Frames Per Second: 10 fps @ 32 kbps video bit rate, 15 fps max
  • Clip Length: 10 - 15 seconds preferred, maximum 22 seconds
  • File Size: maximum recommended 256 KB
  • Preview Files: Shockwave Flash files must be used for preview files going forward.  Detailed parameters will be made available next week.  Ensure it is the same quality as subimtted Mp4 files.

The important thing to consider is as much quality as possible without going below the max file size. Obviously smaller video lengths can lead to improved quality (greater bit and sample rates), so the longer the file is, the greater the sacrifice in quality.  We are flexible as long as the minimums are adhered.

We are currently looking at H.264 technology and whether or not we will be utilizing that for devices going forward.  The technology should be available for the Sanyo 9000 and the Samsung A940.

 

 Video Screensavers Design Guidelines

Video screensavers are movie files that are permanently downloaded to the phone (i.e. non-streaming) and are used by the phone just like any other screensaver type.  These are the specific requirements for creating video screensaver files:

  

  • Pixel Dimensions: 176W x 144H (i.e. QCIF) - This is a hard-line requirement for all Multimedia devices currently.  Any deviation will be annotated specifiecallly by the device within the device specifications below.
  • Recommended Video Codec: MPEG-4 (Mp4/3GP - 3GPP and 3G2 are also acceptable)
  • Video Bit Rate: minimum 32 kbps, maximum 12 kbps (video only, no audio)
  • Frames Per Second: 10 fps @ 32 kbps, 15 fps @ 64 kbps (max)
  • Clip Length: 10 15 seconds preferred, maximum 22 seconds
  • File Size: maximum recommended 256 KB
  • Preview Files: Shockwave Flash files must be used for preview files going forward.  Detailed parameters will be made available.  Ensure it is the same quaility as submitted Mp4 files.

We are currently looking at H.264 technology and whether or not we will be utilizing that for devices going forward.  It should be available for the Sanyo 9000 and the Samsung A940.

 

CMX Design Guidlines

  • Use the most advanced version of CMX for each device instead of the default 2.2 version.  CMX 3.0 and 4.0 offer many improvements in performance and quality and should be used whenever possible.
  • Immediately begin playing the audio track (i.e. MIDI, QCELP, ADPCM or AAC) at the start of the PMD file for all animated ringers.  This allows the user to instantly hear the ringer while the images within the PMD file are being decoded and loaded into memory.
  • Keep the length of the CMX ringer file between 15 22 seconds in length.
  • Place a static PNG image at beginning of the animation.  This allows the user to see an image when the audio starts instead of a blank or default "loading screen.
  • Center all static and animated images on the usable display.
  • Size the images to closely match the actual screen size of each device (or device family).  See Device Specifications for file size and screen dimensions.
  • Use 256K (8bit) color for all images except where specified as 24 bit.
  • Create a user-defined palette in SAF instead of using the default palette.
  • Use simple animations instead of complex animations for CMX 2.2 devices.  This avoids overtaxing the CMX client on the device (skipped frames, skipped audio) and more animation re-work.
  • Avoid using unformatted text messages at the beginning of animation.  Use a PNG image containing graphic text instead.
  • Always use the infinite loop for all animated screensavers (non-audio CMX files).
  • Loop the animation back to the beginning of audio track and animated frames.  Synchronizing the audio and images together prevents a choppy playback when the CMX file loops.
  • Reduce the apparent visual waiting time by starting with a static image right away.  While it is on the screen, you can then begin decoding the SAF animation (.nsp) in the background.  For CMX 3.0 phones, you should be able to get your animation to begin playing in 2 -3 seconds.  For CMX 2.2 phones, this can take up to 4 - 6 seconds.
  • Avoid having more than 2 -3 seconds where the images are not moving or are un-animated.
  • Use scaling as infrequently as possible.  Importing your images into SAF at the size at which they will be displayed will prevent any further degradation (which is inherent in scaling objects larger). Avoid scaling objects smaller (bringing them in as small as they will be displayed) to ensure that your SAF file size is as small as it can be.
  • A technique that can be used for real movie images or something similar is to span png image stills sequentially within CMX. This is as close as we will get to video on older devices that do not support Mp4 or 3D.

 

CMX 2.X CMX3.0 CMX 4.0 CMX 4.3
Audio Formats MIDI, QCELP MIDI, QCELP, ADPCM MIDI, QCELP, ADPCM MIDI(0-1), QCELP, ADPCM, AAC, AAC+
MIDI Voices 16 32 64 64
MIDI Wavetable 35kb 128kb 512kb 512kb
Frames Per Sec 1 (PNG), 2 (SAF) 2(PNG), 3(SAF) 4 (PNG), 6 (SAF) 4 (PNG), 6 (SAF-within CMX only-SAF is still 4fps)
Sample Rate 16 - 22kHz 32kHz 32 kHz 48 kHz
Special Features SAF support, PNG speed up, 24 true-bit color suppot, PCM equalization filter Integrated Mono Wideband DAC, MLZ Decoder, ADPCM 8kHz 16kHz Integrated Stereo DAC, MLZ Decoder, ADPCM 32kHz Integrated Stereo DAC, MLZ Decoder, ADPCM 32kHz, AAC and AAC+ Stereo or mono (AAC or Mp4 format) LC (low complexity) profile (MPEG-2) or object type (MPEG-4) Supported sampling rates are (in Hz) 7350, 8000, 11025, 12000, 16000, 22050, 24000, 32000, 44100, and 48000

 

Also reference the CMX 2.2, 3.0 and 4.0 user guides, support documentation, and test content from Qualcomm's CMX support site @ https://cmx.qualcomm.com.


SPRINT PROPRIETARY INFORMATION - SUBJECT TO NON-DISCLOSURE OBLIGATIONS