I used the official toshiba updater to get an “original” fresh install on my beast and then attempted to run through the install procedure for a single boot rockbox install. After a (seemingly) sucessful install I’d end up in recover mode after any reboot.

Fatal error when attempting to install nk.bin (rockbox only bootloader) using sendfirm in Windows to an updated (v1.2) Gigabeat S player.

After install of both bootloader and rockbox the Gigabeat S, once rebooted, goes into recovery mode (toshiba) and requires an update/restore. This is the Number 3 Triangle.

Notes:
Gigabeat was first updated using the official toshiba MESV12US updater. “gbs_update_1_2_us.exe”

Using SVN revision 19741 to compile nk.bin under WinXP and Cygwin.
Using MTP.zip of 7/4/2008 found on the wiki to send over the bootloader.

I suspect most devs updated their bootloaders using the sendfirm utility *before/without* updating the entire player with the updater utility from toshiba. Thus they started from a v1.1 OF and never updated any part of that.

Maybe the updater changes something in the bootcode. I don’t know.

Build 21245

I have ''Start Screen' set to 'Resume Playback'.

When connecting the Ipod (from OFF) to the PC the Ipod boots and USB mode starts but also playback (the play > sign is display on the title bar).

The Ipod is not shows and not mounted on the PC.

On disconnecting USB I get 'data abort' and have to hard reset.

This isn't a big problem because the MR-100 won't turn on if the hold switch is already engaged.

But if the user turns on the MR-100 and then engages the hold switch while the M:Robe logo is on the screen, a "Hold switch is on Shutting down…" message is displayed, but it does not shut down.

A reset is required at this point - disengaging the hold switch and holding down the power button in this state does not shut down the MR-100.

   I've update my ipod nano 2G to r23629. I found the clickweel would remember the last point my finger leave. And next when I touch the clickwheel, it will make a farward/backward move according to the last point I left, even click the button. Now it is not convenient to type a word with the keyboard inside or setting.
   And my Mac doesn't launch my ipod when I connect my ipod with USB until I change to disk mode. Seems that the USB driver doesn't work.

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

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.

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?

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.

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.

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

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 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!

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.

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.

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.

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.

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.

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).

Hi, this is a codec pack containing all codecs based on blargg's
Game_Music_Emu library.

I have ported all code to C to work in ROCKbox, and i have replaced the
MAME versions of some emulators with others compatible with the GPL license.
It was a lot of work but i did it because i really love chiptune music and having the
possibility to listen to a lot of classic video game system's music in a small player
is really great ;).

Original Game_Music_Emu library here: http://slack.net/~ant/libs/audio.html

Tested on: Sansa Fuze v2
Created from revision: 30084

The following formats are contained in the pack:

- AY (ZX Spectrum, Amstrad CPC)
- GBS (Nintendo Game Boy)
- HES (NEC TurboGrafx-16, PC Engine)
- KSS (MSX Home Computer, other z80 systems)
- NSF, NSFE (Nintendo NES, Famicom)
- SGC (Sega Master System, Game Gear, Coleco Vision)
- VGM, VGZ (Sega Master System, Mark III, Sega Genesis, Mega Driver, BBC Micro)

Additional features:

- 44100 Khz, stereo playback.
- Support all sound chips in NSF/NSFE formats.
- Support MSX-AUDIO and MSX-MUSIC in KSS format .
- Support ADPCM samples in HES format.
- Support for extended m3u playlists created specially for

some chiptune formats.

Known issuses:

- Some (or all) codecs might not work in some targets, specially

if they have an small iram size, or if the codec is too cpu intensive, 
like VGM and KSS.

- Subsong change is not working properly, specially when it happens

automatically.

- Most vgz tracks will be truncated due to the small amount of free

memory available to uncompress them.

- Some SCC+ soundtracks might not work correctly.

** There might be several bugs and issues to be found yet, so please feel free to

  report them here or to my mail address.

Special thanks to:

- Shay Green (blargg) the original author of the great Game_Music_Emu

library.

- Chris Moeller (kode54) who made some nice improvements to the library.
- Mitsutaka Okazaki, author of the YM2413 emulator.
- The OpenMSX team for the YM8950 emulator.
- Stéphane Dallongeville for the YM2612 emulator.
- Joshua Chang, Haiku Konaru and everyone else who has helped me to

test the codecs.

Work in progress patch. Currently decodes audio but with some glitches. Has a small mountain of debug code included.

The basic idea is to rearrange the D filter coefficients in the synthesis filter so that pairs of them are used sequentially. This is not easy because the taps need to be loaded in the seemingly random order needed by the audio samples. However, this rearrangement seems to be possible:

0 1 2 3 4 5 6 7 (original sequence)
0 2 1 3 4 6 5 7 (new sequence)

The complication is that the code assumes that it can start a new filter at any offset, even odd ones, which means each and every filter needs to be rewritten 4 times, one for each of the 4 possible alignments. This patch does that.

Once I'm certain that it works, I intend to convert the D coefficients to packed 16 bit values, then use packed 16 bit multiply instructions on ARMv5E+. This should lead to a small speed up on armv4 (just because ldm instructions can be used instead of ldr) and a very large speed up on arm9E and arm11 (because packed multiplies are tremendously faster and much easier to pipeline).

This patch resorts the v-array within mpc’s synthesis filter. Through this data is placed more locally for the performance critical function mpc_decoder_windowing_D() and allows ldm-usage in the asm’ed parts.

This first patch does work for simulation but not for ARM or CF builds. An update with more optimized ARM asm will follow, CF asm needs to be corrected by someone with knowledge on CF assembly.

The output is binary identical.

This patch adds a new codec that playbacks ZX Spectrum .tap files. Created against trunk (revision 31187)

Hi, this is a new codec based on the SC68 library
by Benjamin Gerard (sc68.atari.org).

Revision: 29484
Tested on: Sansa Fuze v2

Features:

1. 44 Khz Stereo sound.
2. Supports sc68 and sndh files.
3. Support for multi track and single track files.
4. Metadata parsing.
5. Fade out support.

** This codec needs the sc68 Replay folder to work, just put it in the root of
your player. you can find one here: http://aminet.net/package.php?package=mus/play/sc68.lha

Notes:

1.  This is a beta codec, some (big) songs may cause rockbox to crash.
2.  When compiling the sc68 library i had a lot of dependencies errors with
     missing includes.  It is compiling fine now on the vmware image, but not in cygwin.
     I still have to find the problem with that.
3.  Some songs doesn't work, specially some big sndh files.  I'm still working on it.
4.  Seek support is broken, i'm working on it.

Please feel free to make any comment or suggestion.

Continuing from FS#12240, these patches remove most of the rest of the dependencies librbcodec has on the rest of Rockbox.

This first patch is a merge of Tremolo’s bitwise.c and bitwiseARM.s code into rockbox libtremor. As a naive version of the merge, I have taken out the previous rockbox optimisations to huffman decode (originally implemented in  FS#6848 ). Versus svn, decoding speed is worse with this patch. However something that incorporates both  FS#6848  and the Tremolo bitwise optimisations for little-endian ARM may well turn out better. This patch is seriously not committable, the arch-specific stuff is not done cleanly in the headers or the makefile

Continuing from  FS#12204 , these patches remove some of the dependencies librbcodec has on the rest of Rockbox.

0001: puts equalizer settings in the parameters of dsp_set_eq_coefs, removing the need to access global_settings from dsp.c

0002: makes dsp_process yield each iteration instead of once each tick, which is tricky to do portably. If this is undesirable, I can work around it.

0003: moves some replaygain stuff around so dsp.c doesn't have to access global_settings.

0004: instead of dsp.c and tdspeed.c allocating buffers, buffers are allocated elsewhere and passed to dsp_timestretch_enable(). The necessary buffer size is determined by calling dsp_timestretch_get_buffer_size().

0005: replace get_audio_base_data_type() with audio_format_is_atomic(), removing a dependency on TYPE_PACKET_*.

0006: move autoresumable() to playback.c, removing another dependency on global_settings.

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+.

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).

This patch makes some changes to codec_api to help remove dependencies for my project.

The unused strcasestr callback is removed.

The global_settings pointer was being used by several codecs to check whether REPEAT_ONE mode is on; this has been replaced with a callback "should_loop()".

The MOD codec has been modified not to restart the file when it reaches the end. This does not affect MOD files that use "position jump" to loop part of the song. Ideally the MOD codec would only follow such loops if should_loop() returns 1, but detecting loops is nontrivial.

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

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.

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.

As we know, rockbox will use the information provided by "good" mp3 encoders (e.g. LAME) to ignore the extra padding that occurs at the beginning and end of each mp3 file, so that true gapless playback can occur. Unfortunately we do not always have the luxury of encoding our mp3 files in this way but we might still want true gapless playback. This patch compensates for the use of "dumb" mp3 encoders that do not record the necessary information for this feature.

In cases where it does not detect the proper header information to trim off the extra padding, it will optionally skip up to a full frame of silence (or near silence) at the beginning and end of each track (if the trimming is already specified, this patch does not do any additional trimming).

This can potentially eliminate up to a frame of "real" silence at the beginning or end of a track, but in terms of audibility, that would be completely unnoticeable (and it would only happen on these badly-encoded tracks), while the extra silence is an audible annoyance.

I have added an option to the Playback Settings menu so that the user can disable it if desired.

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.

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!

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…

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.

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.

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.

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.

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

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.

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))