Invisible wrote:
> 
> Faulty software is unecessary. It's quite possible to write software 
> that works well, and it needn't even be particularly expensive. 
> (Depending on what it's supposed to do, obviously.) But people can't be 
> bothered, it seems...
> 

Bad software is everywhere, though. Unfortunately, bad software being 
burned to a ROM means that device will likely have bad software forever. 
  Honda is likely using firmware from an outside company. I'd hate to 
find that the same quality software resides in, say, the ECU or the 
cruise control system, or worse: the airbag controller....

But, alas, this is a mere consumer device. They want it done quick, and 
they want it done cheap. The way characters are rendered to the display 
look suspiciously like the characters on my old pioneer MP3 radio. Which 
is somewhat annoying.

( and C are rendered as:
  _
|
|_

I much rather would have preferred ( be rendered as

/
\

But, hey ... what do I know?

And autoscroll would have been nice.



> argue it's HARMFUL TO HEALTH beyond being merely defective... And yet, a 
> bunch of bored hackers on the Internet who don't even have access to the 
> design spec for the player managed to do a better job than paid 
> programmers. I ask you...

They didn't have tight deadlines to hurry up and finish the project? 
They're more talented/driven than the manufacturer could pay for?

> Indeed. There's no reason for it, other than they didn't plan what they 
> were doing properly. If they'd done the job right, it would work.

Likely. Though clipka's theory sounds plausible. Unicode is a tricky 
thing to do correctly anyway. It's not just finding the appropriate 
glyph for a given codepoint, but also how that codepoint is supposed to 
affect the output stream, string normalization forms, RTL and other 
really fun gotcha's.


-- 
~Mike

Post a reply to this message

Invisible wrote:
> I would suggest that the MP3 player is expecting the ID3 tag to be in 
> one specific place, when the standard actually permits it to be placed 
> anywhere.

There's no actual standard for ID3 tags. ID3v1 had to be at the end, as it 
was just a 128-byte fixed-format standard. The later versions were designed 
to be carefully encoded such that no "start of frame" marker (which is 
something like 0xFF 0xFF) appears in them - the integers, for example, use 
only the lower 7 bits of each byte. The idea is that an MP3 player will 
think it's picking up in the middle of a stream and skip over the ID3 tag 
thinking it's the tail end of the previous compressed block of data, then 
start playing.

Sounds like your player is either finding incorrectly-encoded ID3 tags or is 
not looking for the start-of-stream marker before trying to decode things.

-- 
   Darren New, San Diego CA, USA (PST)
   "We'd like you to back-port all the changes in 2.0
    back to version 1.0."
   "We've done that already. We call it 2.0."

Post a reply to this message

Darren New wrote:

> There's no actual standard for ID3 tags. 

Figures.

> The idea is that an MP3 
> player will think it's picking up in the middle of a stream and skip 
> over the ID3 tag thinking it's the tail end of the previous compressed 
> block of data, then start playing.
> 
> Sounds like your player is either finding incorrectly-encoded ID3 tags 
> or is not looking for the start-of-stream marker before trying to decode 
> things.

Yeah. It probably assumes that the first frame will always be right at 
the start of the file or something [because 95% of the time it is].

Post a reply to this message

>> Faulty software is unecessary. It's quite possible to write software 
>> that works well, and it needn't even be particularly expensive. 
>> (Depending on what it's supposed to do, obviously.) But people can't 
>> be bothered, it seems...
> 
> Bad software is everywhere, though.

Sadly yes.

> Unfortunately, bad software being 
> burned to a ROM means that device will likely have bad software forever. 

Almost everything these days seems to hold software in some sort of 
flash RAM rather than actual ROM now. (What does that say about firmware 
reliability?)

> Honda is likely using firmware from an outside company. I'd hate to 
> find that the same quality software resides in, say, the ECU or the 
> cruise control system, or worse: the airbag controller....

Er, yeah. o_O

> But, alas, this is a mere consumer device. They want it done quick, and 
> they want it done cheap.

This seems to be the way these days. Cheapness is the number one 
priority. I'm probably just old and grey, but I swear there used to be a 
time when *quality* was the number one priority... These days it seems 
to be who can make the device for a few pence less than anyone else. 
Because cheap == good, right? *sigh*

>> And yet, 
>> a bunch of bored hackers on the Internet who don't even have access to 
>> the design spec for the player managed to do a better job than paid 
>> programmers. I ask you...
> 
> They didn't have tight deadlines to hurry up and finish the project? 
> They're more talented/driven than the manufacturer could pay for?

Given that there are hundreds of players on the market, many of them 
cheaper and more featureful than mine, you'd think they would want to 
not release it until it was working really well. I guess not...

Still, it boggles my mind that anybody could take a random piece of 
hardware and figure out how the hell to write low-level device drivers 
for it with no technical data at all. I mean, how the hell do they even 
know which CPU it has?!

>> Indeed. There's no reason for it, other than they didn't plan what 
>> they were doing properly. If they'd done the job right, it would work.
> 
> Likely. Though clipka's theory sounds plausible. Unicode is a tricky 
> thing to do correctly anyway. It's not just finding the appropriate 
> glyph for a given codepoint, but also how that codepoint is supposed to 
> affect the output stream, string normalization forms, RTL and other 
> really fun gotcha's.

It's perfectly possible to handle Unicode properly. As clipka says, it 
was probably just a feature they threw in at the end without testing 
properly, that's all.

Post a reply to this message

Invisible wrote:
> Almost everything these days seems to hold software in some sort of 
> flash RAM rather than actual ROM now. (What does that say about firmware 
> reliability?)

It says that FLASH, being mass-produced, is cheaper than ROMs that you have 
to mask on a per-device basis.

Even back in the days of VT100 terminals and TRS-80's, EPROMs were used 
instead of ROMs because it was cheaper, and nobody ever really expected to 
patch the fonts on a VT100 terminal.

-- 
   Darren New, San Diego CA, USA (PST)
   "We'd like you to back-port all the changes in 2.0
    back to version 1.0."
   "We've done that already. We call it 2.0."

Post a reply to this message

Invisible wrote:
> Yeah. It probably assumes that the first frame will always be right at 
> the start of the file or something [because 95% of the time it is].

Not unreasonable, given that it's playing *files*. If it were playing 
streaming media, no, probably a bad idea.

-- 
   Darren New, San Diego CA, USA (PST)
   "We'd like you to back-port all the changes in 2.0
    back to version 1.0."
   "We've done that already. We call it 2.0."

Post a reply to this message

Invisible <voi### [at] devnull> wrote:
> It's perfectly possible to handle Unicode properly. As clipka says, it
> was probably just a feature they threw in at the end without testing
> properly, that's all.

More like, shortly before official deadline for final release, Honda (which
*sure as heck* didn't develop it themselves) during testing happened to find
that scrolling fucked up the system with certain mp3s, complained, the
manufacturer found out it was due to Unicode being used, tried to quickly
implement a fix without success, and settled with Honda on working around by
disabling the scrolling altogether for Unicode in order to be able to deliver
in time for start of production of the new Honda Whatsitsname it was intended
for.

Meanwhile, the issue has been added to the list of items, marked as low
priority, to be fixed "later", when things run more smoothly. I.e. never,
because the new version with more features is already in the making, opening up
new cans of worms.

Been there, seen it - even done that. Not Honda, nor radios, but close enough.

Post a reply to this message

Darren New <dne### [at] sanrrcom> wrote:
> It says that FLASH, being mass-produced, is cheaper than ROMs that you have
> to mask on a per-device basis.
>
> Even back in the days of VT100 terminals and TRS-80's, EPROMs were used
> instead of ROMs because it was cheaper, and nobody ever really expected to
> patch the fonts on a VT100 terminal.

It's a question of quantity.

As soon as the numbers grow big enough, it is more efficient to mass-produce
ROMs that you can just solder onto your board and go for it, than it is to add
in-system programming circuitry and have a production step to flash the
software into each and every individual device.

Provided you don't ever intend to replace the software on the devices.


For instance, the Amstrad CPC home computers came with genuine, custom-designed
ROMs, while expansion devices with built-in software typically came with
EPROMs.


For low-count program-once applications, chip manufacturers even offer "one-time
pogrammable EPROMs", which are straightforward UV-erasable EPROMs inside a
windowless casing, effectively making them PROMs. And I guess some even offer a
programming service. A big advantage of using these is that they're perfectly
compatible with their windowed siblings (but cheaper, and easier to handle in
production because you don't have to put stickers on them), so you can use the
windowed version during development where you'll definitely want to re-program
the things now and then, but the more cost-effective non-windowed one in the
final product, without ever worrying about potential differences in the
operational parameters.

Post a reply to this message

Invisible <voi### [at] devnull> wrote:
>
> This seems to be the way these days. Cheapness is the number one
> priority. I'm probably just old and grey, but I swear there used to be a
> time when *quality* was the number one priority... These days it seems
> to be who can make the device for a few pence less than anyone else.
> Because cheap == good, right? *sigh*
>

I heard that same statement almost verbatim from my father 50 years ago.
I guess it must be human nature to long for the days of our youth when
everything was better than today.

Isaac

Post a reply to this message

> You know why my player uses RockBox? Because the manufacturer's own 
> firmware crashes constantly. That wouldn't be so bad, but when it crashes 
> it sandblasts your ears with very loud sound. One could almost argue it's 
> HARMFUL TO HEALTH beyond being merely defective... And yet, a bunch of 
> bored hackers on the Internet who don't even have access to the design 
> spec for the player managed to do a better job than paid programmers. I 
> ask you...

That's because the bunch of bored hackers have unlimited resources (they can 
take as long as they like until they release anything), paid programmers 
don't.

Post a reply to this message