Help need please guys.

I don't know a thing about software, but need the following, and don't know where to start:

I want to manufacture a product that is a standalone music player, with no control buttons (play, stop, pause etc.), just one on/off button.

The product will be a small box, with an internal drive, and only a headphone output for the signal.

I have about 500MB worth of music files (currently in MP3 format, but can be changed to any), which I want to load onto the internal drive, and play them automatically, in a RANDOM order when the unit is turned on.

Please can someone point me in the direction of how I can have this software written, and what kind of drive I should be looking at.

As you can tell, software/IT is not my personal game, so any help appreciated.

Dani AI

Generated

Short, practical overview for (and following up on about outputs): the simplest, most reliable route is a flash-based embedded player (microSD or eMMC) plus a tiny MCU or low-cost SoC with a DAC and a headphone amplifier. Flash is quiet, low-power and far cheaper and more robust than a mechanical drive for the 500MB music set. For prototypes use a removable microSD; for hundreds/thousands of units consider soldered eMMC or raw NAND to lower per-unit cost and simplify enclosure design.

Recommended software architecture (minimal, deterministic behavior for a single on/off control):

  • Boot, mount a read-only FAT area containing audio files.
  • Build an in-memory index of supported files (MP3/OGG/FLAC as decided).
  • Use a true shuffle (Fisher–Yates) on file indices and play sequentially.
  • Keep a small nonvolatile record of the last-played index if avoiding repeats across power cycles is desired.
  • Avoid runtime writes to the filesystem to prevent corruption on unexpected power loss; write only to a small dedicated NVM slot.

Example pseudocode:

files = scan_mount("/music")
shuffle(files)       # Fisher-Yates
for i in range(len(files)):
    play(files[i])
    if power_lost(): break
save_last_index(i)   # optional small NVM write

Production and QA tips: preload audio during assembly or provide a factory flash image; include a small audio buffer to prevent skips; add hardware debounce on the on/off switch; include pop/click suppression on DAC power-up; provide a simple firmware update path (USB or service pad) and a factory test mode for automated QA. Specify acceptance tests for the firmware: format support, startup time, shuffle distribution, safe power-off behavior, and headphone-level limits. For the first run, a firmware engineer experienced in embedded audio can deliver this as a compact C program or a tiny Linux image—list out exact formats, resume behavior, update method, and physical I/O as required before development begins.

Forgot to say, I'm looking to have 100s or 1000s of these produced, so cost of drive is essential.

will it have internal
speakers or headphones

no internal speakers, it will have phono outputs, a headphone output, and volume control.

Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.