Iriver Vs Iaudio

[Herbatnik]

Mam problem. Chcialbym kupic playerka. Niestety nie moge sie zdecydowac. Mam tu na mysli serie iriver ifp799/899, iriver t10, iaudio 5 1GB. Na poczatku mialem zamiar kupic t10 ale gdy sie dowiedzialem ze nie ma radia i ma z deka ubogie wyposazenie to sie rozmyslilem. Teraz sam juz nie wiem co wybrac.

[Stratos]

Nikt Ci nie doradzi czy lubisz gruszki czy sliwki to owoc i to owoc.. Pamietaj ze iaudio jest tak samo zaawansowane co iriver plus ma radio, wejscie line in. Po prostu Polacy nie znaja tej marki ktora juz jest dlugo na rynku Amerykanskim i Europejskim. Oba player maja najlepsze brzmienie na rynku! lecz roznia sie detalami. Oba maja piekny dzwiek tylko ze nie jest identyczny.... tak samo jest z aparatami jesli porowanasz rozne modele o tych samych parametrach tylko ze roznych firm to kazde zdjecie bedzie miec troche inny odcien! Musisz wybrac na czym Ci zalezy a naczym nie, plus posluchac w sklepie obu playerow pomac ktory lepiej lezy w reku. Playery roznia sie sposobem nawigacji,ksztalem,funkcjami,bateriami itd.

[Herbatnik]

Nikt Ci nie doradzi czy lubisz gruszki czy sliwki to owoc i to owoc.. Pamietaj ze iaudio jest tak samo zaawansowane co iriver plus ma radio, wejscie line in. Po prostu Polacy nie znaja tej marki ktora juz jest dlugo na rynku Amerykanskim i Europejskim. Oba player maja najlepsze brzmienie na rynku! lecz roznia sie detalami. Oba maja piekny dzwiek tylko ze nie jest identyczny.... tak samo jest z aparatami jesli porowanasz rozne modele o tych samych parametrach tylko ze roznych firm to kazde zdjecie bedzie miec troche inny odcien! Musisz wybrac na czym Ci zalezy a naczym nie, plus posluchac w sklepie obu playerow pomac ktory lepiej lezy w reku. Playery roznia sie sposobem nawigacji,ksztalem,funkcjami,bateriami itd.

Dzieki bardzo. Wlasnie troszeczke mialem opory jednak dlatego, ze jakos wczesniej o iAudio firmie nie slyszalem (nie krzyczcie na mnie jestem total laik w branzy mp3 itd...) W kazdym razie w moim przypadku na korzysc t10 przemawia odpornosc (z deka mam dziurawe rece, wiec czesto cos mi z nich wypada:P)... na niekorzysc jednak przemawia ubogie wyposazenie ----> juz raz sie przejechalkem, ze wyposazenie to takze cos . Chodzi mi glownie o cos trwalego. No i nie wiem czy nie kupic czegos wzglednie starszego (ifp899) a bardzo podobnego do czegos nowszego wzglednie (i5). No nic jak ktos by sie jeszcze wypowiedzial to byloby milo.

[Mayhem]

Ja niedawno sprzedałem ifp 899 i byłem już zdecydowany kupić i5 właśnie, tyle, że pojawiła się inna okazja Jak dla mnie przenoszenie muzyki z PC na ifp jest bardzo problematyczne, mimo, że są dwie możliwości do wyboru Przy firmware IMM masz co prawda względnie szybki transfer, ale musisz się męczyć z ****ianym programem IMM i dodatkowo nie możesz bezproblemowo przenosić muzyki z playera na komputer (tylko trzeba podmieniać rozszerzenia - idiotyzm). Z kolei przy UMS nie potrzeba żadnego dodatkowego programu i możesz kopiować w obie strony, ale transfer znacznie spada, co też jest idiotyzmem Dlatego pod tym względem iAudio zdecydowanie wygrywa. O jakości dźwięku nie będę się wypowiadał, bo to subiektywna sprawa, jednym bardziej podchodzi iAudio innym iRiver, ale tak czy inaczej w obu jest ona na wysokim poziomie.

[Stratos]

Ja upuscilem golego i5 (bez pokrowca) na terakote...... czyli nic twardszego nie moglem znalezc hehe. Trzymalem go przy twarzy czyli dosc wysoko i rzucilem w powietrze ale nie......! nie robilem testu Player przezył bez sladu kolizji z ziemia.

Jakosc wykonczenia jest dosc dobra obity jest po bokach metalem, jogi (pokretła) takze sa metalowe, klapka baterii jest na takim miedzianym zawiasie. Usb zatyczka jest na gumowym . W zestawie jest jescze pokrowiec i 2 folie na ekran. Gdy by byl w porkrowcu to bym duzo mniej sie obawial tamtego wieczoru, generalnie to jakos bardzo nie uwazam na player spada mi z łozka, codziennie jezdze z psem rowerem i raz wypadl mi z kieszeni ale sluchawki dosc mocno trzymaja i dzieki temu w wielu roznych przypadkach player nie spadl bo zlapalem sluchawki czy to z okna czy w jakiejs innej sytuacji.

Ale jesli potrzebujesz terenowy player to chyba wez T10 choc oprocz tej klamry to chyba nic nie ma on innych bajerow wzmagajacych jego wytrzymalosc ale ja go nie widzialem wiec nie kieruj sie tym przy wyborze playera.

[KHRoN]

a ja dla kontrapunktu polecam ci jednak T10

 

naprawdę długo trzyma na jednym "paluszku" (jakieś ~35h... i5 ~10 na AAA), dźwięk jest naprawdę wybitny (IMO w i5 jest gożej ;] ), ma najlepszy mikrofon (jakby ci się uwidziało coś nagrać), JEST masywny (o wiele masywniejszy niż i5), odtwarza każde pliki OGG i na OGG gra tak samo długo jak MP3/WMA! (i5 jednak ma z tym znaczne problemy), a "brak radia" przeszkadza tylko osobom które kupiły grajka jako przenośnie radio ;]

 

jak się okazało iRiver to iRiver... miałem iAudio 5... całe dwa dni - stwierdziłem że nie ma sensu

[Herbatnik]

a ja dla kontrapunktu polecam ci jednak T10

heh no to teraz mam dopiero namieszane . Chyba jednak wybiore iriverka, skoro przemawia za nim jakosc. W sumie mam jakas taka dziwnosc ze cenie sobie bardziej jakosc nad piekno i zabawki

[Skręt]

Eee tam, poczekaj na U3 od iAudio

___

 

Ja bym brał T10 ze względu na dzwięk i dyktafon. (a z tym czekaniem to poważnie...)

[djtomas]

a ja bym sprowadzał z USA T10 1GB ze względu na radio i cenę

 

POzdr.

[Forza Lazio]

Skręt dobrze gada Na twoim miejscu bym poczekał

[Stratos]

No ja tez bym poczekal..

Iaudio z i5 bilo naglowe serie IFP Teraz iriver wypuscil nowa generacje ktora nie jest kamieniem milowym w swiecie odtwarzaczy mp3, porownuje sie ja do starszej generacji iaudio i drastycznie jakos nie przoduje.

I6 ma sie ukazac do konca tego roku a jak widac U3 juz sie pojawilo i zapewno znow bedzie duzo lepszy niz jego konkurenci wiec jak sie nie pali to.. poczekaj do swiat. poza tym I5 obsluguje ogg wiec to ze iriver Dopiero teraz wprowadzil ogg nie jest niczym szczegolnym. Dla jednych dzwiek iriver jest cieplejszy,piekniejszy,wybitniejszy a dla nie ktorych nie no i tyle.

Radze Ci wez dwa playery i porownaj i nie sluchaj tych co pieja nad iaudio czy iriverem

[KHRoN]

znaczy obsługa OGG nie jest w i5/G3/U2 wybitna ;] jest porównywalna do tej z iFP "z odblokowanym zakresem odtwarzania" - co udowadnia stopniowe wprowadzanie w firmware kolejnych "jakośći", nienakładanie efektów przy Q9 i Q10 oraz krótsze działanie podczas słuchania OGG... ;]

 

pozatym dwóch albumów w OGG WOGÓLE mi i5 nie odtworzył (pisałem o tym, tylko wtedy nie wiedziałem dlaczego tak się stało - okazało się że kodek był OK bo działają na kompie i T - iFPki i iAudio sobie z nimi nie radzą bo mają zbyt słabe procki ;] ), i5 obcinał dynamiczne początki (mogę dać plik na próbę) i czasem (wyjątkowe fragmenty - dosłownie jeden albo dwa) potrafił przeskoczyć ułamek sekundy...

 

 

więc pełna-pełna obsługa OGG (biorąc pod uwagę flash) jest dopiero w serii T (i nie wiem co z mobiBLU bo nigdzie nie ma i nie mogę posłuchać )

[Herbatnik]

No to chyba rzeczywiscie skusze sie z poczekaniem . Pospiech nie poplaca (przekonalem sie o tym jak kupilem swojego dne-511). A do swiat spokosjnie doczekam. To i pewnie obecne produkty sporo stanieja . Dzieki 4all.

[Stratos]

Własnie przeczytalem ze nowe U3 oprocz mp3,wav i ogg supportuje FLAC............ format ktory jest typowo audiophiliski poniewaz nie posiada straty jakosci z wiekiem co charakteryzuje inne formaty

To chyba pierwszy flash player... tego typu, ciekawe czy bedzie gapless.... jesli tak to Iriver dostanie ostro po pietach ze swoimi nowymi playerami

Ps. no i oczywiscie odtwarza filmy

[Skręt]

Ciekawe co z i6 . Jak i5 jest lepsza od U2....to może w nowych też trzeba się tego spodziewać

[Damianek]

Jak i5 jest lepsza od U2....

 

A w czym jest lepsze??

[Forza Lazio]

też się zastanawiam....

[Skręt]

...dla mnie. Dotychczas większy ekran, nowszy :] no i AAA 20 godzin .

...eee...

Czyli jednak nie jest lepszy tylko inny. Zwracam mu honor.

[KHRoN]

i5/G3/U2 to trzy wcielenia tego samego... coś jak T10/T20/T30 ;]

 

... a czy będzie gapless? nie sądzę do tej pory TYLKO sprzęt SONY jest "gapless" i to tylko odtwarzając ATRAC O_o jakoś nikt się nie pofatygował opracować dekoder dźwięku oferujący taką funkcję... i jeszcze jakiś czas (o ile wogóle) nie pofatyguje...

 

POZATYM pliki MP3 NIE MOGĄ być odegrane zupełnie "bez przerw"... mają dodany ułamek sekundy ciszy na początku i końcu pliku (a WMA i OGG już teoretycznie mogą ;] ):

 

1.   Why is a decoded MP3 longer than the original .wav file?

 

Because LAME (and all other MDCT based encoders) add padding to the

beginning and end of each song.  For an explination of why,

see the questions below.

 

LAME embeds the amount of padding in the ancillary data of the

first frame of the MP3 file. (LAME INFO tag). The LAME decoder

will use this information to remove the leading padding of an MP3 file. 

 

Modifications to the decoder so that it will also remove the

trailing padding have not yet been made. 

 

 

==========================================================================

 

2.  Why does LAME add silence to the beginning each song?

 

 

This is because of several factors:

 

 

DECODER DELAY AT START OF FILE:

 

All *decoders* I have tested introduce a delay of 528 samples.  That

is, after decoding an mp3 file, the output will have 528 samples of

0's appended to the front.  This is because the standard

MDCT/filterbank routines used by the ISO have a 528 sample delay.  It

would be possible to write a MDCT/filterbank routine with a 0 sample

delay (see description of Takehiro's MDCT/filterbank routine used in

LAME encoding below) but I dont know that anyone has done this.

Furthermore, because of the overlapped nature of MDCT frames, the

first half of the first granule (1 granule=576 samples) doesn't have a

previous frame to overlap with, resulting in attenuation of the first

N samples.  The value of N depends on the window type.  For

"STOP_TYPE" and "SHORT_TYPE", N=96, while for

"START_TYPE" and "NORMAL_TYPE", N=288.  The first frame produced by

LAME 3.56 and up will always be of STOP_TYPE or SHORT_TYPE.

 

 

 

ENCODER DELAY AT START OF FILE:

 

ISO based encoders (BladeEnc, 8hz-mp3, etc) use a MDCT/filterbank

routine similar to the one used in decoding, and thus also introduce

their own 528 sample delay.  A .wav file encoded & decoded will have a

1056 sample delay (1056 samples will be appended to the beginning).

 

(actually, the observed delay is 1057 samples.  For even more

technical discussions about this, see the mp3encoder mailing list

archive)

 

 

The FhG encoder (at highest quality) introduces a 1160 sample delay,

for a total encoding/decoding delay of 1688 samples.  I haven't tested

Xing.

 

Starting with LAME 3.55, we have a new MDCT/filterbank routine written

by Takehiro Tominaga with a 48 sample delay.  With even more rewriting,

this could be reduced to 0.  And there is no reason an inverse routine

could not be used in a decoder.  However, there are a few problems

with using such a short delay:

   

 

1.)  The 96 samples of the first frame are attenuated by the MDCT

     window.  If the encoder delay is greater than 96, this window will

     have no effect since the first 96 samples are all padding.  With a

     48 sample encoder delay, the first 48 samples will be improperly

     attenuated. (.001 seconds worth of data at 44.1kHz). 

 

2.)  Filterbank contamination problems.  This it rather technical, see

     below.

 

3.)  In LAME, psycho-acoustics for the first 576 granule are not correct. 

     This could be fixed, but at the expense of adding more buffering

     and code complexity.

 

If points 1. 2. or 3. do not bother you, you can decrease the

the encoder delay by setting ENCDELAY in encoder.h.  The default

right now is 576. 

 

More technical details on very short ENCDELAY:

Here is an example:

 

 

                    granule 1         granule 2 

                    576 samples       576 samples

                | 192 | 192 | 192 | 192 | 192 | 192 |

data:           <    all zeros'   >< real  data     >

short block   <--------->

                    <--------->

                           <--------->

end block                       <---------------------->

 

output:                           | 192 | 192 | 192 |

 

 

granule 2 is the first granule that is encoded.  granule 1 is

the fictitious previous granule that doesn't really exist, except

that the output of the decoder for granule 2 is going to be combined with

the data in the buffer which would have held the decoded output of

granule 1.  I will assume the decoder initializes this buffer with

zeros. 

 

Lets ignore quantization.  The lapped MDCT followed

by the IMDCT is lossless.  That means that the IMDCT output

from granule 2  when added to the IMDCT output from granule 1

is identical to the input. 

 

In our case, the decoder just sets the granule 1 IMDCT output to all

0's because it never actually computes this and is just initializing a

buffer.  But the output of granule 2 IMDCT is computed correctly.

 

output = granule_1_output + granule_2_output

 

granule_1_output:  encoder uses all 0's, which is incorrect since

                   the MDCT (if it was performed) would have seen

                   some of the data in granule 2. 

                 

granule_2_output:  correct

 

Therefor, the output will be correct *except* where it uses data from

granule 1, but this can effect at most the first 96 samples.

 

However, the polyphase filterbank is another story:

 

The data (with first 96 samples corrupt) is then sent to the

inverse polyphase filterbank.  I dont know much about how this

albatross works, but I think it has an effective window length of

512.  So the bad data in the first 96 samples can corrupt

samples up to 96+512. 

 

 

 

 

 

==========================================================================

3.  Why does LAME add silence to the end of each song?

 

Extra padding at the end of a file can be caused by a couple of things:

 

1.  Because the MDCT's are overlapped, it looks something like this:

 

<--576 MDCT coefficients--><--576 MDCT coefficients--><--576 MDCT coefficients-->

            <-- 576 samples PCM output --><-- 576 samples PCM output -->

 

   So no matter where you truncate your MP3 file, the last 288 samples of

   that granule will not be decoded.  So LAME appends 288 samples of

   padding to the input file to guarantee all input samples will be

   decoded. 

 

 

2. If the number of samples is not an exact multiple of 1152,

   then last frame of data is padded with 0's so that it has 1152 samples.

 

 

Before lame3.56, we just added a few extra frames to make sure all

internal buffers would be flushed.  In lame3.56, we tried to pad

with the exact minimum number of samples needed.  And in lame3.80,

we finally fixed the bitstream flushing so that the final mp3

frame is properly padded with ancillary data. 

 

 

==========================================================================

4.  Why cant MP3 files be seamlessly spliced together?

 

There are several reasons this is *very* difficult (but not impossible):

 

The MP3 data for frame N is not stored in frame N, but can be spread

over several frames.  In a typical case, the data for frame N will

have 20% of it stored in frame N-1 and 80% stored in frame N. 

If the encoder builds up a large bit reservoir,

the data for frame N can actually be stored 4088 bits back in

the bitstream.  Then if a very hard-to-encode passage comes up,

then the encoder is free to use the normal bits for this frame

plus up to 4088 more.  The resulting data will then take up

several frames.   The starting negative offset

in the bitstream for the data associated with a given frame in bytes is

given by main_data_begin.

 

Thus chopping a mp3 file on a frame boundary will almost always result

in the corruption of the data in that frame.   mpg123 will report

such errors as "cant seek past beginning of file" or something

like that. 

 

A proper cut-and-past job could be done, but it would have to

separate all the data from the frame headers, and then

replace the frame headers in the correct location in the new

stream.  One problem:  this may generate data for frame N that

is stored too far back, say 4100 bits back.  In that case, the

main_data_begin field will be incorrect since it can be at most 4088.

 

Two possible solutions:

 

1. Create mp3's with the --nores option in LAME,

(disabling the bit reservoir and reducing quality somewhat),

these mp3 files can be simply cut and pasted on frame boundaries.

 

2. Use VBR and overlapping encodes.  For example:

   stream A = encode frames 0-99

   stream B = encode frames 97-200

 

   First remove the frames 97,98 and 99 from stream B.  It is

   important to use overlapping encoding because of the

   psycho-acoustics.  Then take frame 100 in stream B.  Most of the

   time, some data for frame 100 will be stored in frame 99.  Take a

   look at frame 99 from stream A.  If there is enough space, take the

   frame100 data which was stored in stream B/frame 99, and store it

   in stream A/frame 99.  If there is not enough space, replace frame

   100 with a higher bitrate frame to make enough space.

 

   Now stream A and stream B can be concatenated together. 

 

 

Note that MP3 stores MDCT coefficients which represent 1152 samples,

but they are overlapped by 50%.  So for example:

 

frame N     <  0...1152    >

frame N+1         <  576...1727   >

frame N+2                  <   1152...2304   >

 

You need to add all the data together to complete the frame.  The

complete frame of samples 576-1727 needs frame N, N+1 and N+2.

[immanuel]

POZATYM pliki MP3 NIE MOGĄ być odegrane zupełnie "bez przerw"... mają dodany ułamek sekundy ciszy na początku i końcu pliku (a WMA i OGG już teoretycznie mogą ;] ):

 

w IMP-350 w którymś z nowszym firmware'ów nie było słychać przerw w ogóle

[KHRoN]

z jednej strony teoria sobie, praktyka sobie (dowodzą tego specjalne tagi określające "ile ciszy pominąć" tagi np.: by Creative ;] )...

 

... jednak ja się jeszcze ze sprzętem odgrywającym pliki MP3 bez przerw nie spotkałem (były mniejsze/większe ale były)... nie licząc programów a la foobar2000/winamp... ale wiadomo że mając taką moc obliczeniową i wyspecjalizowane (= zupełnie ba bakier ze standardami ) dekodery można zdziałać wiele