I wonder why there is no recent edit... the rockbox iRiverport has greatly progressed for two months... It's still unable to play audio files due to codec lack but the things are on the way and according to one of the Rockbox members the audio support will come very nearly (less than a month)

I've the confidence that the first player with MPC playback will be the iHP1xx thanks to Rockbox wonderful work....

I also find it interesting that monkey's audio is listed in the list of possible supported codecs (depending on hardware), because that would basically mean that code for parsing ape-tags is there and could also be used to read ape-tags from mp3s.

I also find it interesting that monkey's audio is listed in the list of possible supported codecs (depending on hardware), because that would basically mean that code for parsing ape-tags is there and could also be used to read ape-tags from mp3s.

- Lyx

Hi Lyx,To be clear i've to precise some little things.

the MonkeyAudio presence isn't the assurance that MAC will be supported by Rbx... Although I have NO skill in coding nor in audio codec I've personnaly added the AAC, APE and MPC informations in the codec part to motivate skilled coders... In fact i'm quite sure the hardware is able to play APE, thats won't be the matter...The only question will be: "Is there people skilled in and motivated to implement a decoder (or a coder for encoding part) in the Rbx iRiver port???"

About motivation I've discussed a little with one Rbx member who's working on the iRiverport for a while (LinusM to name him) and he assumed that:

QUOTE

As we have said earlier, we don't mind having a zillion codecs in Rockbox.

However, even if the Rbx team is very competent, they have no expericence in codec developping since their Archox Rockbox firmware didn't provided software codec cause those Archox players are using hardware codec (an encoding/decoding chip)...

I'm pretty sure the Rbx team can release a fully functional Rbx firmware for iHP, with decompressing ability for at leats usuals codecs (mp3, rawPCM in WAVE Conteners and maybe Ogg Vorbis))

But I guess things will progress faster with the competences of some talentuous coders of the HA "sphere" (if they are interested). And especially concerning some "exotics" codecs used by the audiophile people, i.e. mostly the HA population: MPC of course but also AAC, and obviously lossless codecs as APE and others...

About the APE tag parsing i guess if the team decide to provide APE codec support tehy will get interest in APE tag format too...

About the mpg123 questioni've to say that i think the Rbx chosen codec fr mp3 playback is the MAD decoder...

What are the advantages of mpg123?

/!\Just keep in mind the Wiki section of the Rockbox iRiverport is WIKI! You can edit everything when logged. So if you see something wrong or something lacking feel very free to edit it!!!!!

Gapless playback via lame-headers. This means that mp3-tracks which have seamless trackchanges and which were encoded with lame, can be played back gapless. The mp3-format usually is not gapless - but lame stores some data in its headers which makes it possible to have gapless playback with mp3s although the format usually doesn't support it.

I'm not sure if this is part of the mp123 decoder, but both, the modified mp123 decoder of foobar, and the winamp mp123 decoder both support ape-tags in mp3s and both make use of replaygain. But as i said, i dont know if this is just a coincidence or indeed part of the decoder itself.

Hum oki Lyx, thanks...Strangely the Rbx team said us that seamless playback even for mp3 would' not be an issue with a well made Rbx firmware...

I imagine this mean that the seamless playback isn't really linked with the decoder itself but with his modification...About RG the Rbx team also said that was absolutely possible to implement its support...

Anyway I guess Peter (zzzzz) can answer if the GAPLESS playback for Lame mp3 is due to mp123 or if it's added to the codec when modding it for fb2k...

I just mailed David Bryant telling him about this possibility of hardware support for WavPack. He just moved to San Francisco, so he doesn't have time to follow HA closely these days, but I'm sure he will be glad to help the Rockbox developers with any issues that might arise (he also has lots of experience with embedded development, which is a plus)

One final note: It's WavPack or Wavpack, not Wavepack

--------------------

Get up-to-date binaries of Lame, AAC, Vorbis and much more at RareWares:http://www.rarewares.org

I just mailed David Bryant telling him about this possibility of hardware support for WavPack. He just moved to San Francisco, so he doesn't have time to follow HA closely these days, but I'm sure he will be glad to help the Rockbox developers with any issues that might arise (he also has lots of experience with embedded development, which is a plus)

One final note: It's WavPack or Wavpack, not Wavepack

I'm very thankfull Roberto it's more than nice... Thanks a lot for the mail to David Bryant! The rockbox crew is happy to see that there is contact possibility with the authors in case they encounter a big difficulty...of course it's really not time to annoy him as he's moving...

Anyway the encoding devlopmment won't begin so early, for the moment the crew is working on realclocking the CPU (which is quite underclocked for now)...Then tehy will begin with mp3 decoding...

After taht encoding will be considerated... But wavpack (sorry for bad spelling, i've edited) appears very interesting to them...

Wow. This could make me actually buy a iHP. Is iRiver aware of this project? What do they think about it? Will they help it at all? By the way, why are the folks at rockbox looking for an integer lossy encoder? Because of the built-in recording capabilities? Will they use wavpack lossy?

Wow. This could make me actually buy a iHP. Is iRiver aware of this project? What do they think about it? Will they help it at all? By the way, why are the folks at rockbox looking for an integer lossy encoder? Because of the built-in recording capabilities? Will they use wavpack lossy?

Hi Emtee,About Iriver i don't knowx if they are aware of the Rockbox project but it's not usefull to notify them and it could be a real BAD idea...indeed there have been two others project of iHP alt firmwares and the first one have been stopped by the authors due to iRiver pression... (that's what they said)

There is no need to connect rbx with iriver firmware section which is well known fo hi uncompetence... It won't help rbx and it may cause some issue...

PS: nothing to add to Roberto explanation about the integer lossy encoder...

Hi Emtee,About Iriver i don't knowx if they are aware of the Rockbox project but it's not usefull to notify them and it could be a real BAD idea...indeed there have been two others project of iHP alt firmwares and the first one have been stopped by the authors due to iRiver pression... (that's what they said)

There is no need to connect rbx with iriver firmware section which is well known fo hi uncompetence... It won't help rbx and it may cause some issue...

PS: nothing to add to Roberto explanation about the integer lossy encoder...

Well, I own a CD-based iRiver player, and I'm happy with the firmware updates iriver provides. Sure, they aren't realeased every month or so, but the firmware is pretty stable and they even listened to their customers when asked for vorbis support.I obviously won't notify them, that's the project's authors decision. But I'm not sure if iRiver would react negativelly. It's not like they're cracking or reverse engineering iRiver's original firmware - they're building one up from scratch, which might be more convenient to power-users, and can raise iRiver's sells. So unless there are some kinds of legal problems, iRiver should aknowledge the project and help them out. Pretty much like the Fedora Core/Red Hat relationship. I might be missing something, though.