H120 not starting original IRiver Firmware with LCD Remote holding Rec + Play Button both on LCD-Remote.

I am trying to use the last method mentioned on the ipodpatcher wiki page to write Rockbox directly into the OSOS image on my iPod Nano2G. Sometimes it works properly, but other times it fails saying that it couldn't read the header from the .ipodx file. I am following the instructions exactly, so that can't be an issue. I have tried hexediting the .ipodx file, and in some cases I can get ipodpatcher to read the header by editing the first four values, but this always causes a Checksum Error. Here is the exact output:

C:\Users\Michael Marley\Downloads>ipodpatcher.exe -wf rockbox.ipodx
ipodpatcher 5.0 with v4.0 bootloaders (v1.0 for 2nd Gen Nano)
(C) Dave Chapman 2006-2009
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

[INFO] Scanning disk devices… [INFO] Read XML info (4 bytes)
[INFO] Ipod found - 2nd Generation Nano ("winpod") - disk device 1
[INFO] Reading partition table from \\.\PhysicalDrive1
[INFO] Sector size is 2048 bytes
[INFO] Part Start Sector End Sector Size (MB) Type
[INFO] 0 63 48194 94.0 Empty (0x00)
[INFO] 1 48195 1982462 3777.9 W95 FAT32 (0x0b)
[INFO] Read XML info (4 bytes)
[INFO] Ipod model: 2nd Generation Nano ("winpod")
[ERR] Failed to read header from rockbox.ipodx
[ERR] –write-firmware failed.

I got no SD-Card support for my E-250 after boot into USB mode.
I plug in my powered off player into usb and only have access to internal storage.

If i plug in my player booted up there is no problem.

I am using daily build r29174-110131.

Since r30937, the e200v2 bootloader is too large and mkamsboot errors with:

[ERR] Packed data (120926 bytes) doesn't fit in the firmware (120860 bytes)

Steps to reproduce:
1. build e200v2 bootloader
2. cd to rbutil/mkamsboot
3. run make to create the mkamsboot utility
4. run mkamsboot <path-to-e200pa.bin> <path-to-bootloader-e200v2.sansa> <path-to-output.bin>

Rockbox Info: Version: 3.12

Device: iRiver H140, 80GB Toshiba MK8009GAH 8mm 1.8" IDE HDD 8mm

BUG: Repeatable, Consistent.

Additional Information:
1. To verify that I had a good installation of the 3.12 version of the Rockbox firmware working, I have reformatted, and re-flashed rockbox 3.12 two seperate times after initially encountering this, duplicating this behavior. So it doesn't seem to be a bad firmware flash.

Expected Behavior:

1. Player should Power On and boot properly every single time the bootup sequence is initiated correctly (Play Button pressed when Player is in a Powered Off state).

Buggy Behavior:

1. Player Powers Up, then locks up (i.e. "crashes") during bootloader sequence, requiring a hard reset, and upon second boot, finally Powers On and boots properly, bringing up a functional session of the Main User Interface. This is repeatable, and consistent.

Bug Symptoms & How To Repeat:

1. Consistently the Player will lock up during first "boot" sequence. The bootloader will usually reach the text stage, and sometimes crash here. Sometimes the bootloader will get through the text stage and reach the Rockbox Logo and then crash here. The Main User Interface is never reached upon first "boot" sequence.

2. The result of the first "boot" lockup (i.e. "crash") requires that I reset the Player by inserting a paperclip into the Reset hole (on the bottom plate of the Player) and triggering the button hidden in there. This Powers Down the Player, and Resets the Firmware, leaving the Player ready to be Powered On again.

3. Upon the second "boot", the Player will "boot" and the bootloader will make it past the text stage, the Rockbox Logo stage, and then spin up the HDD properly; the bootloader will not lock up the firmware, and behaves 'normally', finally resulting in a completed boot up sequence with the Main User Interface coming up (as a user would expect). The Player is now ready to use.

Alarm wakeup doesn’t work reliably. It is unclear whether the setup is wrong or the wake up is. It might be that the player wakes up before time because of a small press on the power button and thus somehow forgets about alarm.

This patch changes the iriver H300 series bootloader's power and usb handling. When a USB or Power plug are inserted into the H300, it will now boot as normal, not stop in the bootloader usb/charging modes. This was mainly for use in my car, but is also helpful for people with charging cradles for their computers.

Forum thread can be found here http://forums.rockbox.org/index.php?topic=17202.0

So, when you compile and run the bootloader on VX767/VX757 or any other buttons-only model, it can only boot to the Rockbox or the OF. It cannot use USB mode or reset RB configuration.

Here is a patch.

Hi,

There is a compilation problem when the environment variable BLOCK_SIZE is set. It gave me errors about a comma.

This can be set or cleared systematically or on a command by command basis.

Suggestion one; unset BLOCK_SIZE and its relatives high in the build chain, but be prepared for POSIX to bite with 512 byte blocks.

Suggestion two; set LS_BLOCK_SIZE=1 high in the build chain. (And DF_BLOCK_SIZE=1024 and DU_BLOCK_SIZE=1024 ?)

Suggestion three; edit apps/lang/Makefile so that

$(SILENT)echo “#define MAX_LANGUAGE_SIZE `ls -ln $(OBJDIR)/* | awk ‘{print $$5}’ | sort -n | tail -1`” > $(HEADER)

becomes

$(SILENT)echo “#define MAX_LANGUAGE_SIZE `ls -ln –block-size=1 $(OBJDIR)/* | awk ‘{print $$5}’ | sort -n | tail -1`” > $(HEADER)

or

$(SILENT)echo “#define MAX_LANGUAGE_SIZE `LS_BLOCK_SIZE=1 ls -ln $(OBJDIR)/* | awk ‘{print $$5}’ | sort -n | tail -1`” > $(HEADER)

Suggestion four; just tell people that they are not allowed to have commas in their core utilities output (and be prepared to be bitten badly if the default block size ever changes).

BTW I *like* having thousands separators on my command line, so I have

export BLOCK_SIZE=\'1
export DF_BLOCK_SIZE=\'M

in my /etc/bashrc file.

The H10 5G MTP needs a different bootloader than the UMS version (see http://www.rockbox.org/twiki/bin/view/Main/IriverH10PortDevInfo#Build_a_Rockbox_Bootloader).
I’m not sure about the correct way to do this in configure, so I’ll leave it to someone who is.

The uisimulator cannot be build by using the source of the latest version on MinGW.

I send this bug’s patch.

It is necessary to apply the patch of FS#10021 to build the firmware on MinGW.

Tested at r29689, gcc 3.4.4. When trying to create a voice file in Cygwin, the following comes out (taken from STDERR):
librbspeex.a(rbspeex.o):rbspeex.c:(.text+0x453): undefined reference to `_speex_nb_mode'
librbspeex.a(rbspeex.o):rbspeex.c:(.text+0x45a): undefined reference to `_speex_wb_mode'
librbspeex.a(rbspeex.o):rbspeex.c:(.text+0x462): undefined reference to `_speex_encoder_init'
librbspeex.a(rbspeex.o):rbspeex.c:(.text+0x490): undefined reference to `_speex_bits_init'
librbspeex.a(rbspeex.o):rbspeex.c:(.text+0x4b9): undefined reference to `_speex_encoder_ctl'
librbspeex.a(rbspeex.o):rbspeex.c:(.text+0x4d9): undefined reference to `_speex_encoder_ctl'
librbspeex.a(rbspeex.o):rbspeex.c:(.text+0x4f6): undefined reference to `_speex_encoder_ctl'
librbspeex.a(rbspeex.o):rbspeex.c:(.text+0x513): undefined reference to `_speex_encoder_ctl'
librbspeex.a(rbspeex.o):rbspeex.c:(.text+0x527): undefined reference to `_speex_encoder_ctl'
librbspeex.a(rbspeex.o):rbspeex.c:(.text+0x5fd): undefined reference to `_speex_resampler_init'
librbspeex.a(rbspeex.o):rbspeex.c:(.text+0x609): undefined reference to `_speex_resampler_skip_zeros'
librbspeex.a(rbspeex.o):rbspeex.c:(.text+0x6ac): undefined reference to `_speex_resampler_process_int'
librbspeex.a(rbspeex.o):rbspeex.c:(.text+0x6fc): undefined reference to `_speex_encode_int'
librbspeex.a(rbspeex.o):rbspeex.c:(.text+0x724): undefined reference to `_speex_bits_write_whole_bytes'
librbspeex.a(rbspeex.o):rbspeex.c:(.text+0x7c0): undefined reference to `_speex_bits_write'
librbspeex.a(rbspeex.o):rbspeex.c:(.text+0x81d): undefined reference to `_speex_encoder_destroy'
librbspeex.a(rbspeex.o):rbspeex.c:(.text+0x829): undefined reference to `_speex_bits_destroy'
librbspeex.a(rbspeex.o):rbspeex.c:(.text+0x83d): undefined reference to `_speex_resampler_destroy'
collect2: ld returned 1 exit status
make[2]: * [../rbspeexenc] Error 1
make[1]: * [rbspeexenc] Error 2
make: *** [voicetools] Virhe 2

When I try to build rockbox, I get the following error:

=⇒ make: execvp: /bin/sh: Argument list too long
⇐=

My build path is a fairly long path. Building it at a location with shorter path it works. Details:

Steps to reproduce:

* Create a location where you want to have the sources; use a fairly long path name, e.g.

  mkdir -p /home/myuser/download/mediaplayer_hardware/SanDisk/Sansa_Fuze_v2/rockbox/firmware/source/

* Change to that directory:

  cd /home/myuser/download/mediaplayer_hardware/SanDisk/Sansa_Fuze_v2/rockbox/firmware/source/

* Download git sources (Tried with version from 2014-09-22, 10:55:11 GMT+1, Commit by "Marcin Bukat marcin.bukat@gmail.com", Change-Id: "Ie3aa9b208e3f4f17d4d02f11f69839e9b381217d") to a long path:

  git clone git://git.rockbox.org/rockbox 

* Make a build directory and change into it:

  mkdir -p /home/myuser/download/mediaplayer_hardware/SanDisk/Sansa_Fuze_v2/rockbox/firmware/source/build_FuzeV2
  cd /home/myuser/download/mediaplayer_hardware/SanDisk/Sansa_Fuze_v2/rockbox/firmware/source/build_FuzeV2

* Configure the build:

  ../rockbox/tools/configure --target=63 --type=N

prodces the output

==>

Using temporary directory /tmp
Platform set to sansafuzev2
Normal build selected
Using source code root directory: /home/myuser/download/mediaplayer_hardware/SanDisk/Sansa_Fuze_v2/rockbox/firmware/source/rockbox
Using arm-elf-eabi-gcc 4.4.4 (404)
Using arm-elf-eabi-ld 2.20.1.20100303
Found and uses ccache (/sbin/ccache)
Automatically selected arch: arm (ver 5)
Created Makefile

<==

* Running "make":

  make

produces the output

==>

Generating dependencies
make: execvp: /bin/sh: Argument list too long
make: *** No rule to make target '/home/myuser/download/mediaplayer_hardware/SanDisk/Sansa_Fuze_v2/rockbox/firmware/source/build_FuzeV2/make.dep', needed by 'all'. Stop.

<==

and returns with exit code 2.

Workaround:

Building it in a directory with shorter path, e.g. doing everything in "/tmp", works.

But that is only a workaround; it should not fail when building in arbitrary locations, and especially not with a message not making it clear _what_ the underlying problem ist. (I had to do a long internet search to get to the idea that the build place can be the problem).

I am trying to build Rockbox for Sony NWZ-380 from Git repo, commit ce0b31d87db3c4c1c1bfb535c50770d33e9c4aaf.
arm-elf-eabi-gcc version 5.4.0, ARM binutils 2.30.
Everything goes smooth until just the latest step where this happens:

… LD duke3d.ovl
LD bmp.ovl
LD jpeg.ovl
LD png.ovl
LD ppm.ovl
LD gif.ovl
LD rockbox.elf
/usr/libexec/gcc/arm-elf-eabi/ld: section .ARM.exidx VMA [00000000600a9548,00000000600a954f] overlaps section .bss VMA [00000000600a7f20,00000000600ff773]

I'm using Rockbox on my NWZ-384 for a couple of years now and there were no problems building it in the past. I also was very glad that NWZ-380 port reached stable status in 3.14,
but now something seems to be broken (not terrible it seems, just requires some adjustments to the linker scripts but still).

Trying to cross-compile GCC for the ipod with GCC 9.2 I keep running into errors:

In file included from ../../gcc-4.4.4/gcc/diagnostic.h:25,

               from ../../gcc-4.4.4/gcc/tree-mudflap.c:43:

../../gcc-4.4.4/gcc/pretty-print.h: At top level:
../../gcc-4.4.4/gcc/pretty-print.h:310:6: error: ‘cgraph_node’ is not defined as a type

310 |      ATTRIBUTE_GCC_PPDIAG(2,3);
    |      ^~~~~~~~~~~~~~~~~~~~

This would seem to be the same issue as the one described on https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90677

The attached patch against GCC seems to fix the problem for me.

If you’re willing to produce a Human voice file (spoken by you or someone you know), this script will be particularly helpful. It expects you to put it in a directory with a subdirectory containing .wav files for all voice strings, named by the contents of the string (this will be problematic on FAT/NTFS, but could be fixed).

When run, it will check to see if all needed strings are available, and if they are, it will generate a voice-file for all targets. If they aren’t, it will print out a list of strings missing (to be recorded and put in the subdirectory). This list will also be put in the file “missingstrings.txt”, one on each line.

This might be suitable for inclusion in tools/

Edit: Script deleted. Will upload again soonish.

It would be useful to change the configure and voice.pl files in order to allow the user to choose also the Loquendo and ViaVoice TTS

This is an attempt to automate the setting of $PATH in tools/rockboxdev.sh, tools/configure and the generated Makefile.

The directory prefix of the cross compilers is stored in ~/.config/rockbox.org/RockboxCompilerPrefix. As the default path (in tools/rockboxdev.sh) is /usr/local, if that file is empty, then $PATH won’t be modified. Otherwise, the value stored inside that file will be read, the target platform type appended, and lastly /bin appended. The resulting string will be appended to $PATH.

This patch doesn’t break existing configuration. But it’s most probably incomplete, so please provide feedback on which files need to be modified as well.

This patch modifies bins.pl, manuals.pl and voices.pl to be smarter, just like the new w32sims.pl, adding a -r commandline switch, allowing the same script to be used for building both daily and release versions.

Building Rockbox fails if assert() (in firmware/include/assert.h) is used.

Then, I reworked assert.h.

changes:
When assert() failed, the correction that displayed the file name, the number of lines, and the condition of failing was done.
Moreover, when the log was enabled, the log was output to the file.

Please select the following to make assert() enabled when you make Rockbox.

1) Run tools/configure

2) Build (N)ormal, (A)dvanced, (S)imulator, (B)ootloader, …

    Select "A"

3) (D)EBUG, (L)ogf, (A)ssert, (S)imulator, (P)rofile, (V)oice

   Select "A"

4) make

The Rockbox firmware and cross compilers build by using MinGW.

It is necessary to use MSYS’s make (MinGW’s make (mingw32-make) does not used.).

The cross_compilers.zip is a patch file necessary to make cross compilers using by rockboxdev.sh.

I confirmed the Rockbox firmware, codecs and plugins was built by using the compiler on MinGW.
But I can not confirm whether the Rockbox executes excluding iPod video.

Could you confirm operation to various players?

The patch fix the multiple-language feature, maintaining the same behaviour in interactive and batch mode and with “make reconf”. Now it’s possible to build more than one voice language at once, specifying different engine and option set for each one.
So, running “make voice”, all the selected languages will be built.

To help the comprehension, here it is a batch mode sample:

../tools/configure –target=ipodvideo –ram=64 –type=av –language=italiano,espanol –tts=f,e –voice=lp_diphone –ttsopts=, –encopts=’-q 10 -c 10,-q 5 -c 5’

This is like to run:

../tools/configure –target=ipodvideo –ram=64 –type=av –language=italiano –tts=f –voice=lp_diphone –ttsopts=’ ' –encopts=’-q 10 -c 10’

../tools/configure –target=ipodvideo –ram=64 –type=av –language=espanol –tts=e –voice=lp_diphone –ttsopts=’ ' –encopts=’-q 5 -c 5’

In the first case, I set the language to italian, using festival with voice lp_diphone (female), no further festival options and some manual encoder options.
In the second case, I set the language to spanish, using espeak. Even if I set the voice, the value is ignored, since the selected TTS engine doesn’t use it.

I also added some cosmetics, like some very circumstantial indentation, blank check in rootdir too, simpler numbered menu generation, some terser command pipes.

The patch is applied to r22250.

I don’t know if it’s a really wanted feature, but the word in the script hurt me!

These two scripts will, if you run them appropriately generate a few screenshots in an automatic fashion. Execute it like this, from inside a simulator: ./genscreenshots e200.xte /path/to/output

There are a few pitfalls:
* The simulator window MUST gain focus when it is run. If this doesn’t happen, everything breaks. Horribly.
* The method is rather timing sensitive. I had to put a pause of 250ms between each keypress to make sure they registred (too fast, and the sim/SDL would discard them). 250ms may not be the right amount for your computer.
* Rockbox itself is also timing sensitive. If you “push” a button at the wrong time, it may not register, so use plenty of sleeps to make sure things are settled.

Edit: Oops, the first version had a hardcoded filename. Hopefully of such things.

RB does not play AC3 tracks which were extracted from DVD with splitting one-track/one-song (splitting by chapters).

In other words - if you extract single AC3 song RB will not be able to play it back, despite the fact foobar2000 and Winamp with AC3Filter plugin will play it fine.

It is not a problem related to extracting software as the problem occurs for AC3 files saved by DVD Audio Extractor and SmartRipper. (Files saved by them are bit-bit the same as file comparison showed).

Simulator does not display any debugging info when you try to play AC3 file which RB is unable to play.

AC3 playback is not completely broken because RB plays AC3 files if you extracted full AC3 track without splitting it.

When you play back a broken flac file (in this case a file that was truncated) it can happen that he decoder outputs constant loud noise instead of just skipping to the next track.

I’m not sure if this is really a bug since you are not supposed to play back broken files.

Attached is a file where this happens.

H300 r18009 (happens in the uisim too).

I have only tested this on my H120 with an 18007 build. I have been using the APE codec for some time now and never had a problem in the past.

After reformatting my hard drive and installing the current build I found that rockbox has 2 problems with my APE files

1. The parser for APE files no longer recognizes my APE files encoded with version 8,9 of Jriver Media Center. Result is that files don't play when selected in the file browser and these files do net get added to the database.

2. When switching APE tracks one of two possible behavior occur. a) the Iriver freezes completely. b) On switching tracks there is a loud hiss and then playback of the next track resumes.

Cheers

  Thomas

Hello World :)
Attached is a VBR WMA music file, which fails to play correctly on my “RockPod” iPod Nano.
The same file decodes perfectly using the latest ffmpeg build.
Therefore I can only assume there is something about this file which triggers a bug in the Rockbox-specific WMA decoder.
Also attached is a microphone recording of the sound which comes out of my iPod when Rockbox attempts to play the faulty WMA.

I have over 3000 WMA tracks, all encoded using an identical method, all of which will not play correctly in rock box, so if you would like any more examples, or information, please ask.

Thanks for all your help :)
(If there is any way I can help debug/update the code for the wma decoder, please let me know where to start, I understand the C source code pretty well)

~Andrew

also category:
Some containers, like Matroska MKA or like Ogg can contain numerous audio tracks, for example the whole AudioCD contained within single Ogg file.

For example VideoLAN.org plays such files ok, while fails to show separate tracks/tags in playlist.

However, RockBox justs freezes and until reboot can no longer play music (each file is detected as having zero duration)

example can be found: [link deleted - it was a full copyrighted album]

This is actually release 3.5.1

I have quite a few low bitrate .wma audio files that play fine in the original firmware, play fine in VLC, but skip, stutter, and hiss in Rockbox.

The file is 20kbps, 22 kHz, mono, Windows Media Audio V2.

I have attached a sample cut from a larger file. Like the original files, it plays fine in the original firmware and in VLC.

decode_packet in wmaprodec.c returns -1 almost immediately, most likely due to being passed corrupted data by the ASF parser, although I have not confirmed that to be the case. I've seen similar issues in WMA Std. Theres probably some ASF feature we do not correctly implement.

Hardware: Clip+ 8GB using internal memory
Problem: Playback of most APE files results into passages of loud noise during playback. The music is totally gone and noise is ear deafening loud. When rewinding, till music is heard, and replaying the problem part, error can be reproduced _sometimes_.
In other cases it either runs fine, or the problem occurs elsewhere in the file.

Since the problem does not always occur in a specific part of a APE file, it is hard to attach a sample file.

Problem persisted between ape files encoded in high and normal setting.
Using winamp + monkey audio 3.99 APE plugin, these files never shown problems.

When I play non-protected WMA files of 32 - 64 kbps and 44khz which have been ripped without changing anything from video on my Clip+ I get a garbled sound. I hear bits of sound all mixed up. This was true w/ 3.81 firmware and now w/ 3.9. The unexpected thing is that they all play normally w/ the Sansa firmware(Sansa firmware's volume is too soft for my taste Roll Eyes).

I am reopening  FS#11501  - Sansa Clip v2 FLAC playback skips regularly, which was closed because a sample file was not provided. I didn't think this was necessary because I stated it happened regularly with just about any file.

I am currently on build 30217. It skipped for me last night on this track:
http://www.archive.org/download/johnbutlertrio2011-07-24.lsdII.flac16/johnbutlertrio2011-07-24_lsdII_t07.flac

I cannot attach the track to this ticket because it is larger than 2mb.

Again, it is nothing inherent in that track: a second playthrough did not skip. That 16-bit/44.1khz track was generated with FLAC 1.2.1b using normal procedures.

This problem has occurred for any build I've ever tried on a clip v2 player.

Here is my original problem statement:

Build 27566 (and all previous builds), Sansa Clip v2.

playback of 16-bit/44khz FLAC format regularly will skip ahead to next track.

in a 60 minute playback session, it'll probably happen 2-3 times. this is not due to a defect in the FLAC files. it happens with any FLAC set I attempt.

this does not happen with the Clip v1 on the same build number.

this is my first bug submitted. I searched for duplicate reports but didn't find anything.

thank you!

I downloaded some AAC files from the bbc, using the get-iplayer utility. The files play just fine on the computer, but on my rockboxed Clip+, they seem to freeze up the player entirely. I have to hold the power button for a long time to reset it. I just tried updating to rockbox 3.9, but I'm not seeing any difference with the new firmware.

When I play the file in mplayer, it gives the following info:
major_brand: M4A
minor_version: 512
compatible_brands: isomiso2
encoder: Lavf52.64.2
========================================================================Opening audio decoder: [faad] AAC (MPEG2/4 Advanced Audio Coding)
AUDIO: 44100 Hz, 2 ch, s16le, 48.0 kbit/3.40% (ratio: 6000→176400)
Selected audio codec: [faad] afm: faad (FAAD AAC (MPEG-2/MPEG-4 Audio))

The .ape file I join make rockbox produce a horrible noise (like random audio) when seeking inside it. The original file was very large, so I created this one with:
dd if=original.ape of=test.ape bs=512 count=1000
So the produced file may not be correct, but it plays correctly in rockbox, and reproduces the bug, so I join it…

All i know is that this happened on 590mb tta file and after cutting it with cue splitter there was no problems with playback.

SVN:31187

When playing a sequence of two songs Rockbox on my HTC Desire S always crashes. I first had r30576-110921, and now it is r31516-120102. Cropped versions of the songs can be downloaded here:

http://www.vlado-do.de/rockbox/01_Wenn_die_Nacht_am_tiefsten_03m_08s_09h__03m_23s_22h.ogg http://www.vlado-do.de/rockbox/02_Wir_m%C3%BCssen_hier_raus_00m_00s__00m_28s_82h.ogg

They still reproducably crash my Rockbox. I found a workaround, though: mp3 versions of the same songs play all right. Rockbox for me still is the only known way to have gapless playback on my phone. Thanks for that guys!

Buy the way: the same ogg files made no problem in Rockbox on my old iPod nano.

as3525
Version: 91b52a1-120122

Running on Sansa clip zip, unable to play the following .ogg file (I can't try it on other Rockbox versions, maybe someone can?). Works fine played any other way.

www.quik.clara.co.uk/Wontplay_inrockbox.ogg

(too large to attach directly)

I have some stereo files that need to be encoded as two independent channels with no lossy stereo coupling. I encode these files by passing "–uncoupled" to the Opus encoder, e.g.

opusenc –bitrate 64 –framesize 60 –uncoupled example.wav example.opus

The lossless flac version of a sample of such a file prior to encoding can be downloaded from
http://kyle.tk/binaural-beat-sample.flac

If I do not pass the "–uncoupled" option to the encoder, the resulting Opus file plays with no trouble on my Sansa Clip+. The sample of this encoding is at
http://kyle.tk/binaural-beat-sample-64k.opus However, if I pass the "–uncoupled" option, sample at
http://kyle.tk/binaural-beat-sample-64k-uncoupled.opus Rockbox only plays a cacophony of chirps, scratches, squeaks and garbled noise, and no hint of the original sound is detectable.

Note: I have only been able to test this on a Clip+, as I own no other Rockbox player that is capable of playing Opus files at this time. Hopefully someone can confirm this problem on other targets, but for now, I have been able to reproduce it 100% on the Clip+, and I can confidently point to "–uncoupled" as the encoder option that results in an unplayable file.

When listing to a mp3 for some time there starts a massive random noise in the background. It will continue for some time when pausing or stopping playback and will also continue when starting another track.
I’ve noticed this when listening to a random list of mp3s of various sources and using speedup with 225% or 250%.

At the moment I’m using ee758c5 with my clip+.

First noticed the issue in the previous dev build, and just confirmed in 15fa7f8.

When playing .opus files, no metadata is displayed. Some files (92kbit stereo music files so far) do play fine otherwise. Others induce crashes upon attempting to play. An example is attached.

First test, I played a couple of music files successfully, then tried to play the attached file. System crashed immediately showing the following:
“Undefined instruction
pc:30000002 sp:300632[display cuts off here]
bt end”

Powered off, restarted, and tried to play the attached file immediately. After a second or so of audio, player crashed again:
“Undefined instruction
pc:08180002 sp:302029[display cuts off here]
bt end”

On the previous dev build, I was getting similar errors if I tried to play the attached file (or several other similar ones) after successfully playing other files, but would get a black-screen crash if I tried to play it immediately on powerup (this is not what is happening on 15fa7f8).

I am NOT experiencing these problems on another AMSv1 player (Sansa c240 [”c200v1”]) with the same dev build, so this may be specific to the Clipv1. On the c240 with both the previous build and 15fa7f8, metadata displays fine and the attached file plays without any apparent error.

After playing a few opus files (~128 kbps) the system becomes so unresponsive that it cannot decode the file in real time, and the device cannot respond to any input within a reasonable timeframe (have to hard power off).

This does not occur when you set the cpu frequency beyond the highest setting in the debug menu!

To reproduce:
play opus files in a playlist with normal cpu scaling
on beginning of 2nd or 3rd file, system will become unresponsive.

http://www.konscience.de/wp-content/uploads/kns017-maertyrer-gegen-copyright.m4a

The current build as well as 3.13 report and then fail:

parsing /kns017-maertyrer-gegen-copyright.m4a failed (format: ALAC)

However, foobar reports:

Codec profile : AAC SBR

Which is likely correct given that the bitrate is far too low to be ALAC.

There is an ALAC playback problem in daily builds (since 2014-11). The playback somethimes works for one song but then crashes and shows ALAC file details as "? kbit/s", "0 MHz", "0 MB" and nothing happens when I press the Play button. After reboot the problem occurs again. It makes the ALAC playback impossible.

Now I'm using revision 9cb9f76M-140326 with patches from aroldan:

https://www.dropbox.com/sh/b5xbw6cp4ikfxwn/MjELjmDNJ_

With this build there are no ALAC playback problems.

When playing music, I can hear codec errors in the music. It occurs every time on a certain song, and other songs that are smaller in file size, it does not occur on, but occurs on the next one. I believe it is a buffering issue, and makes the music unlistenable. I used the daily on 10/21/2015

On 320kb/s MP3s it occurs much more often, and 128kb/s MP3s it occurs less often, but when it occurs its a series of glitches that distort the music.

I am sure its not the MP3s themselves, because it doesn't occur in the official firmware, and when I rewind it, it does not make the same sound until later. It has a very prominent 'glitchy' sound and later it changes the speed of the song.

I replaced it with the 3.1.3 MP3 codec, and the same glitch occurs.

I do not have a line out so its made through the speaker, but the problem is so bad that you can hear it very clearly.

The MP3 was 320kb/s

Memo is the glitchy one, and Memo-1 is it being played correctly.

Create silence in Audacity program (Generate → Silence). Convert the wav file to ogg vorbis file. Put into the sansa clip+ player wav and Ogg files. Turn on the equalizer and set 32 hz, 64 hz, 125 hz in the 0.5-2.0.
Turn on maximum volume. Listen to the silence of wav file. Absolute silence. Listen Ogg Vorbis file - hear the noise (like the wind). It’s bug with only ogg vorbis. mp3, flac, mp4 is absolute silence.
On a musical files it’s additional noise. Ogg vorbis is economical of disk space. Testing on a sansa clip+ with 2GB.

I primarily use my unit for audio books while driving, but the latest build (as I write this) won't play one of the files properly. It tries to start, stuck at 0:00. Trying to seek hangs the player altogether, requiring a hard restart.

I've recreated this problem on a flaky Clip+ and an AGPTek Rocker.

The 'file' tool identifies it as: ISO Media, MP4 v2 [ISO 14496-14]

Here's what mplayer has to say (while playing it back properly):

[lavf] stream 0: audio (aac), -aid 0, -alang eng

Please refer to forum post for full exchange: http://forums.rockbox.org/index.php/topic,52518.0.html

In summary playing ALAC will crash the unit, other codecs not as much. My reasoning is (as contained in the forum post):

Converting some of my ALAC collection to FLAC to test has given excellent results = no crashes. I am suspicious of the ALAC decoder; watching the VIEW BUFFERING THREAD there seems to be consistency:

OGG/MP3/FLAC/WAV: CPU Frequency goes up to 124 until pcm: becomes full, then drops to 45mhz and pcm: hovers (it is always active) near the top of 100%. Upon track change the cycle starts again (124mhz until pcm: becomes full). I don't seem to get crashes.

ALAC: CPU Frequency goes up to 124 until pcm: becomes full, then drops to 45mhz and pcm: quickly goes down (takes about 2 seconds) to 75%, then cpu switches to 124mhz to get pcm: back up to 100%. This goes on constantly (cpu high - low cycle) while a single track/file is playing. I am now believing this cpu going up and down constantly gives me the crashes. Note on crashes: I don't know when they will happen, sometimes after a minute or two, sometime after 10 minutes , there is no pattern I can tell.

Playing 320K MP3s pauses often in Version 3.15 and daily build 7d00533 also UI becomes unresponsive
Version 3.14 or older does not reproduce the issue in either 44 or 48khz sampling rate and same sound options
Is not reproducible under OF or Version 3.15 running on IPOD 6G
seems to be a cpu usage issue as compiling a version of rockbox with much higher than stock CPU clocks seems to alleviate the issue to an extent but there is still occasional pauses that is not present after reverting to 3.14 and stock 80 mhz clock speed.

Playing APE 24/44.1 with harsh noise in different parts of the track. If you decode APE file to WAV using the codec console, then there are no problems. So the matter is in the player’s APE decoder.

At 24/48 everything is fine.