Arm Ukraine, zap Putin

Stolen Votes logo logo

No Cookies

Flag UK DE





No Tracking





Review of MP3 (& WAV) player, USB Vendor 0x066f, Product 0x8000

0x066f = Sigmatel

By Julian H. Stacey - Index of other texts.



  • Manufacturer unknown, but China.
    (The ones I reviewed were promotional items badged by pharmaceutical company MSD also labelled with their service Univadis); - Names not relevant to this analysis, but explains old name this page moved from).
  • Features
    • Plays MP3 music
    • Also works as `dictation machines' ie they record human voice to a .wav file. (.wav are about 10 times more space consuming than mp3)
    • Supports deep directories ie you can have contemporary/group_name/album_name/track_name.mp3
    • Runs on a single removable battery, either normal Zinc Carbon or rechargeable NiMh. Comes supplied with a normal Zinc Carbon battery.

      I had suspected the player Might recharge batteries if left plugged in to USB, Reason:

      • USB 5V 500mA is more than enough for a 1.5V small battery.
      • CDROM that came with it has a readme.txt starting: "This is the customized Windows host software for SigmaTel MSCN Audio Player. Please verify that all the text and graphics are acceptable and let us know immediately if any changes are required.
        This is a USBMSC host software implementation and will require USBMSC firmware (built using sdk 2.400 or later)"
      • Wikipedia says: "Over 150 portable mp3 player models use the STMP35xx highly-integrated low cost audio System On a Chip (SOC) that requires no external RAM, voltage converters, battery chargers, headphone capacitors, Analog to Digital Converters, Digital to Analog Converters, or amplifiers, and over 100 million such portable audio player SOCs were sold from 2002-2006."
      But it does not seem to recharge off either a powered USB hub, or laptop USB direct. However, no problem, removable battery (AAA) is same size as in my optical mouse & DEC-T phone both of which recharge, & also fits in a generic external charger (not included).
    • Names appear on file system (seen by computer) can be long (ie longer than DOS 8.3), & can be lower or upper case.
    • Names shown on player display are shown shortened.
    • Standard small jack is near mini key ring so compatible with hook of hang round neck ear cables
    • I don't know what the hold knob does, maybe for microphone recording.
  • Capacity nominally 512M on sticky label. Actually a bit less: (Not a lot by modern standards, For Comparison, at 2009.10.21, another similar size player (in food supermarket Tengelmann), was about 24 Euro).
    fdisk da0
    cylinders=118 heads=64 sectors/track=32 (2048 blks/cyl)
    Media sector size is 2048
    Warning: BIOS sector numbering starts with sector 1
    The data for partition 1 is:
    sysid 6 (0x06),(Primary 'big' DOS (>= 32MB))
        start 48, size 242256 (473 Meg), flag 80 (active)
            beg: cyl 0/ head 1/ sector 1;
            end: cyl 630/ head 7/ sector 48
    The data for partition 2 is: <UNUSED>
    The data for partition 3 is: <UNUSED>
    The data for partition 4 is: <UNUSED>
    Block size 2K (unusual, normally sticks are 512 bytes). Unit I tested was. 242304 x 2K = 496238592 bytes,
  • File system from factory:
       1825 May 22  2007 ./HERO.lrc
    4167053 May 22  2007 ./HERO.mp3
       1744 May 22  2007 ./PrettyBoy.lrc
    6692864 May 22  2007 ./PrettyBoy.mp3
        471 Dec 27  2002 ./SETTINGS.DAT
       7770 Dec 27  2002 ./VOICE/V001.WAV
    HERO.lrc:       ISO-8859 English text, with CRLF line terminators
    HERO.mp3:       MPEG ADTS, layer III, v1, 128 kBits, 44.1 kHz, JntStereo
    PrettyBoy.lrc:  ASCII English text, with CRLF line terminators
    PrettyBoy.mp3:  Audio file with ID3 version 23.0 tag, MP3 encoding
    SETTINGS.DAT:   data
    VOICE/V001.WAV: RIFF (little-endian) data, WAVE audio, IMA ADPCM, mono 8000 Hz
    SETTINGS.DAT    A binary file. Safe to delete as proven by me:
            { Deleting, Un-mounting, Power On, Settings, Power
            off, Mounting, Observe A new settings file (different,
            probably on a different song number).
        ( Intriguingly both new & old have date of Dec 27  2002 ).
    *.lrc       Lyrics in Ascii, to some standardised format.
    VOICE/V001.WAV  Sample noise, tapping.
  • USB Connectivity to PC: A lot more stable than Clipman, Connection doesn't seem to keep coming & going (like Clipman, which could crash OS,
    Speed: 1,812,634 bytes/sec via a Belkin USB-2 Cardbus adapter (might have been a raw read ?).

    Speed. Via a Belkin USB-2 Cardbus adapter, to a single large file on the file system: date ; testblock -v -n dummy ; date Will write then read. Block size 61440 (0xf000). 9 mins 28 sec = 348 sec, for 483,901,440 bytes = 1,390,521.4 bytes / sec = 11,124,171 bits/sec. That's 3 times faster than Clipman

  • Software Looks like a USB stick (except block size) so no special software needed. Runs fine with FreeBSD-7.2 Which is Free Software
  • Manual is not consistent with player.
    • Manual says its shows software version number, But it does not, instead it shows space used & remaining. Even if you remove SETTINGS.DAT & reboot, it still wont show revision number (which might have been nice, to get a clue what formats are supported, per Wikipedia article).
    • Manual says it lists Chinese as a language, as well as English & Spanish But player has no Chinese, but does also have German & French etc
    • Manual lists lots of frequencies to record at, But player only allows 8 KHz
  • Top Of Page


2K Media Blocks Are A Problem for BSD fsck_msdosfs

Below is a copy of postings 1st March 2013 to FreeBSD then copied to NetBSD,
click on either to read any follow up.

Source code src/sbin/fsck_msdos/boot.c

cc: gdt@@@NetBSD,,,
    Tom Rhodes <>
Subject: sbin/fsck_msdosfs does not handle media with 2K blocks
From: "Julian H. Stacey" <>
Date: Fri, 01 Mar 2013 01:45:03 +0100

cc: gdt@@@NetBSD,    (< grep @ src/sbin/fsck_msdosfs/*.c)
cc:          (< man newfs_msdos)
cc: Tom Rhodes <>    (< man 5 msdosfs>

sbin/fsck_msdosfs (FreeBSD 9.1-RELEASE) fails on 2K block media,
media in this case, an mp3 player:

sysctl kern.geom.debugflags=16
        kern.geom.debugflags: 16 -> 16

/sbin/fsck_msdosfs /dev/da0s1
            ** /dev/da0s1
    could not read boot block (Invalid argument)

    "vendor" "0x066f"; "product" "0x8000"; "devclass" "0x00";
    "devsubclass" "0x00"; "intclass" "0x08"; "intsubclass"
    "0x06"; "intprotocol" "0x50" ; "release" "0x1001";

/sys/dev/usb/usbdevs: vendor SIGMATEL         0x066f  Sigmatel

dd if=/dev/da0   bs=2k of=da0   # 242304+0 records  496238592 bytes
dd if=/dev/da0s1 bs=2k of=da0s1 # 242256+0 records  496140288 bytes
echo "2048 242304 * p" | dc #           496238592
echo "2048 242256 * p" | dc #           496140288

fdisk /dev/da0
        cylinders=118 heads=64 sectors/track=32 (2048 blks/cyl)
        Media sector size is 2048
        Warning: BIOS sector numbering starts with sector 1
        Information from DOS bootblock is:
        The data for partition 1 is:
        sysid 6 (0x06),(Primary DOS, 16 bit FAT (>= 32MB))
            start 48, size 242256 (473 Meg), flag 80 (active)
                beg: cyl 0/ head 1/ sector 1;
                end: cyl 630/ head 7/ sector 48

( I think this unit's FS got corrupted. Possibly as part of media error ?
  This unit (when not USB connected, but powered on battery as a
  player, flashed its LCD display on & off, (same warning as to also
  indicate a low battery) whereas other units of same type with
  same battery powered up OK, & battery is OK, so player is probably
  also seeing a bad FS. )

I tried this:
    sysctl kern.geom.debugflags=16
    dd if=/dev/da0s1 bs=2k of=image
    mdconfig -a -t vnode -f image
    /sbin/fsck_msdosfs -y /dev/md2
        ** /dev/md2
        ** Phase 1 - Read and Compare FATs
        ** Phase 2 - Check Cluster Chains
        ** Phase 3 - Checking Directories
        /audio has entries after end of directory
        Extend? yes
        /audio has entries after end of directory
        Extend? yes
        long filename record cluster start != 0
        Invalid long filename entry for volume label
        Remove? yes
        ** Phase 4 - Checking for Lost Files
        139 files, 60280 free (7535 clusters)
        ***** FILE SYSTEM WAS MODIFIED *****
    ... Repeating fsck above, shows the same errors above ...
    newfs_msdos -F 16 -S 2048 /dev/md2
        newfs_msdos: Cannot get number of sectors per track,
            Operation not supported
        newfs_msdos: Cannot get number of heads,
            Operation not supported
        newfs_msdos: trim 21 sectors to adjust to a multiple of 63
        /dev/md2: 242192 sectors in 15137 FAT16 clusters
             (32768 bytes/cluster)
        BytesPerSec=2048 SecPerClust=16 ResSectors=1 FATs=2
            RootDirEnts=512 Media=0xf0 FATsecs=15 SecPerTrack=63
            Heads=16 HiddenSecs=0 HugeSectors=242235
    /sbin/fsck_msdosfs -y /dev/md2
        ** /dev/md2
        ** Phase 1 - Read and Compare FATs
        ** Phase 2 - Check Cluster Chains
        ** Phase 3 - Checking Directories
        ** Phase 4 - Checking for Lost Files
        1 files, 484384 free (15137 clusters)
    mount -t msdosfs /dev/md2 /mnt
    cp SETTINGS.DAT /mnt
    umount /mnt
    mdconfig -d -u 2
    dd if=image bs=2k of=/dev/da0s1
        dd: /dev/da0s1: Input/output error
        80+0 records in 79+0 records out
        161792 bytes transferred in 32.715037 secs (4945 bytes/sec)
    ... Remove & Reinsert & waited for devd & unmounted after auto-mount...
    Repeated dd & same error.
    ... Remove & Reinsert & wait for devd automount
    ls /usb/sigmatel    ... it has the new empty FS with SETTINGS.DAT
    ... but still the LCD flashes
    fdisk -B /dev/da0
        fdisk: /boot/mbr: length must be a multiple of sector size
    cat /boot/mbr /boot/mbr /boot/mbr /boot/mbr > /boot/mbr2k
    fdisk -B -b /boot/mbr2k /dev/da0
        Should we write new partition table? [n] y
    ... still the LCD flashes
    fdisk -i /dev/da0
    fdisk -u /dev/da0
    ( Not Tried: newfs_msdos with -s 512 to see if the Sigmatel chipset
        will play it, but not much point as fdisk says 2K ... )

So it seems this particular unit has a problem (that other units
of same manufacture here do not have). I can't think what else to try ?

It seems I discovered a limitation in FreeBSD (while doing the above):
    We should hack various sources to [also?] allow R/W of 2K
    media blocks , eg inc. here:
        #define DOSBOOTBLOCKSIZE 512
        readboot(int dosfs, struct bootblock *boot)
        u_char block[DOSBOOTBLOCKSIZE];
        if (read(dosfs, block, sizeof block) != sizeof block) {
            perror("could not read boot block");
    Who might best hack those sources ?
    Maybe someone since 1997 Wolfgang Solfrank & 1995 Martin Husemann
    be interested?

Note another Odys player MP X30 V Multimedia Player, (vendor=0x10d6, product=0x1101 in devd.conf ) does not use 2048 but 512, (so not all mp3 players use 2048 (as someone speculated they might), (though Cdroms & DVDs use 2048 though)).

Top Of Page


Stolen VotesBerklix.Net Computer AssociatesDomainsApache: Web ServerFreeBSD: Operating System