Talk:ATRAC

128 kbps vs. 132 kbps

Shouldn't be every occurence of "128 kbit/s" bitrate replaced with 132 kbps? Has someone more information? Picasso Pablo 11:54, 18 April 2006 (UTC)[reply]

The 132kbps bitrate is used by the original ATRAC3 codec, which corresponds to LP2 mode on the MDLP recorders. The 128kbps bitrate is used by ATRAC3plus codec, and its support is limited to few devices, PSP and some Flash Memory based Walkmans. None of the Minidisc units nor ATRAC CD Players support the 128kbps bitrate. 69.228.3.99 00:13, 28 July 2006 (UTC)[reply]

Doesn't ATRAC files (.oma extension files) have DRM encryption?

.oma files, which add DRM encryption, use ATRAC encoding, but not always the other way around. For years, MiniDisc players did not have DRM and used ATRAC. It wasn't until recently, with the advent of the NetMD and recorders that could upload files through a non-audio interface, that DRM has been used.

Likewise, SCMS, which has always beeon used on the MD, as well as DAT and DCC and is also a form of DRM, isn't strictly part of ATRAC. Because of this, if Sony decided to make a video game system or car stereo or new type of telephone and needed to compress audio, they could use a chipset supporting ATRAC and not use any form of DRM if they wanted to.

--Jkonrath 21:41, 14 Mar 2005 (UTC)

Lossiness of MD recording

Please see the discussion at Talk:MiniDisc. I think that there's a contradiction between the two articles.--Amir E. Aharoni 21:43, 21 December 2005 (UTC)[reply]

Resolved? --KJ 04:01, 23 December 2005 (UTC)[reply]

Not really, MiniDisc still says the "this data can be thrown away without creating a noticeable difference in the perceived sound" and ATRAC says that it is worse than an MP3.

I came here, 'cuz there was a discussion about the quality of MD recording vs. DAT on a bootleg-sharing site that i frequent. That site's rules strongly discourage even high-quality MP3's and encourage FLAC, but someone claimed that recording anything to MD is already as lossy as an MP3... So if "no noticeable difference" is the same MP3, then there is a difference. While a difference between CD and MP3 is easily noticeable, i never noticed a difference between CD and ATRAC (without further MDLP compression), but then i'm not an expert audiophile...--Amir E. Aharoni 09:12, 23 December 2005 (UTC)[reply]

I don't see how that constitutes a contradiction. Some data can always be discarded without creating a noticeable difference in perceived quality for some people. It's a matter of how many people can notice the difference, and people who are attuned to lossy artifacts can hear ATRAC3 artifacts more easily than they can hear MP3 artifacts, at the same bit rate. Anyway, edited. Would it be resolved now?

I'm sure you're not listening to ATRAC hard enough, or not doing a fair comparison. If you think you are, then you might need to check out double-blind testing. --KJ 15:55, 23 December 2005 (UTC)[reply]

ATRAC3 LP2 Mode section

The double blind test referenced used VBR MP3, which is stated in the article. But VBR generally does sound better than constant bit rate, so surely to say that this test shows that 132 kbps ATRAC3 sounds worse than 128 kbps (CBR implied) is invalid. --Nathan (Talk) 00:45, 5 January 2006 (UTC)[reply]

So how do you propose it should be changed? While the logic in the article may be invalid, 132kbps ATRAC3 probably does sound worse than 128kbps MP3. --KJ 04:01, 17 January 2006 (UTC)[reply]

Without knowing the exact details of the tests (double blind or otherwise) it's impossible to really make a judgement about ATRAC. It is also essential to consider the bit rates as well. I have seen it claimed that Codec X is better than Codec Y, yet this may apply - if at all - only at low bit rates, or a specific bit rate. Thus WMA probably does sound better than MP3 at 32 kbps, but at 64 kbps there may be much less difference. At higher bit rates the differences between codecs tend to be slight.

One must also look into the conditions of each test more carefully. One test which was done by experts from the BBC, and several other broadcasting stations, and appears to have been done satisfactorily, "showed" that no one could tell the difference between original source material and audio encoded at 192kbps. Investigation shows that the original source material was only a few seconds long - as this presumably makes the testing feasible - and possibly did not contain audio sufficiently challenging to show up any significant differences. Most music will encode well - with most codecs - at 192kbps, but if you watch the encoder (say an MP3 encoder) operating in VBR mode on complex music you may notice that there are occasional patches which encode at 256 kbps. Listening to these patches usually reveals that these are critical audio highlights. Usually the edge is taken off these if they are encoded at 192kbps or lower.

One concern I have about ATRAC is the possibility of transcoding artefacts, as the audio may be repeatedly processed when using tools such as SonicStage. At times one wonders if sufficient care has been taken with even simple things, like anti-aliasing filters. However this is somewhat speculative, and without doing many tests one cannot claim that this is definitely the case.

There may well be problems with ATRAC, but without knowing the exact details of the test which "proved" this, then it's really unwise to make strong judgements.

Maybe it's best just to use whichever system works for you! I have heard some really good ATRAC recordings, and some really poor ones. At the end of the day, compression does discard information, so it's a compromise between perceived quality, storage space and transfer times, and users have to decide what's convenient for them.

David Martland 07:38, 28 February 2006 (UTC)[reply]

NPOV Check

When I came to this article this afternoon looking for some technical information, the layout of the article caught my eye as it seems to fail to completely adhere to the NPOV requirements. Looking further, a number of lines were deleted as of April 1st and other lines changed(all without citations), significantly shifting the tone of the article. The revision prior to this also seems to be weighted however, so I am not convinced the edits of April 1st were malicious, but I am not an expert in compression in any way, so I can not objectively determine what the proper description should be.

Overall, I find this article lacking in both a proper NPOV position and in citations for the double-blind tests mentioned, and hence am nominating it for a NPOV check as part of a larger process to correct the shortcomings in this article.

User:163.120.75.137 15:40, 4 April 2006 (UTC)[reply]

Gapless track transition

I understand that the ability to have gapless transitions between tracks is a major feature of ATRAC that is not supported by many other compression methods. To me, this is at least as important as differences in perceived sound quality that are so small that people argue interminably about them.

I think the article should refer to this in some way. Is there someone who could do that knowledgeably? Unfortunately, I'm not qualified to do that with the level of rigour that I would hope from Wikipedia.

83.70.87.26 05:27, 8 May 2006 (UTC)[reply]

There's nothing special with ATRAC compression, AFAIK, as far as gapless playback is concerned. It's got more to do with how a MiniDisc player handles cue points. --KJ

I accept that the player (in my case, a hard disk player not MiniDisk) has its part to play, but I would have thought that the compression format also has to support the precise insertion of cue points so that the player can avoid playing the silence at the end of the last block of the track. I've tried LAME encoded MP3 and WMA. I get momentary pauses with the MP3 and very significant pauses with WMA (due to a larger encoding block size?). A general trawl of the internet suggests that there is something special about ATRAC that enables precise cue points to be handled in the player. The Wikipedia article on gapless playback that you quote supports this but doesn't explicitly mention ATRAC. It does, however, refer to MiniDisk as an "optimum solution" which implies that ATRAC is special in that it incudes a precise cue point in it's metadata. I just think it would be worth referring to this in the article on ATRAC.

83.70.87.26 22:13, 8 May 2006 (UTC)[reply]

Can you clarify what you're talking about here? 'Gapless playback' generally means that the player doesn't insert silence between the tracks, but if (as there usually is) there is silence recorded at the end of each track, it won't remove it. LAME MP3 is certainly capable of this. (In older versions you had to ask, but it's now standard.) A modern LAME track played on a computer should be gapless in this sense. Henry ^Flower 22:21, 8 May 2006 (UTC)[reply]

The article gapless playback explains this fairly well. To clarify what I mean, there can be three types of silence at the end of a track. (1) The silence that is intended to be there, if any. (2) Silence that results from the encoder padding out the last encoding block in the track. (3) Silence that is added by the player if it is not ready to play the next track when the current one ends. By "gapless playback" I mean playing (1) but not playing (2) or (3). In other words, exactly as it was originally recorded in this respect. To avoid (2) you need a compression format and encoder that supplies information to the player which identifies where the original track ends, and a player that makes use of this information. If there is intended silence at the end of a track, it probably doesn't matter if a short amount of type (2) or (3) silence is added. But, if there is no intended silence, types (2) or (3) silence can be very intrusive.

83.70.87.26 23:36, 8 May 2006 (UTC)[reply]

Compression schemes do not support cue points, plain and simple. Gabriel Bouvigne of the LAME MP3 project has stated this a few times, saying that if MP3 isn't gapless, then neither is Vorbis. (To which my usual counter is, "But Ogg Vorbis is.") --KJ 00:14, 9 May 2006 (UTC)[reply]

See gapless playback, specifically the section "Optimal solutions". The method described may not be a "cue point" as such, but it is effective. And it is implemented in ATRAC encoders.

83.70.87.26 00:47, 9 May 2006 (UTC)[reply]

I'm the person who put that there, [1] and I don't agree. Besides, it's possible to do it with no cooperation from the encoder, as long as you know about the encoder beforehand. --KJ 01:13, 9 May 2006 (UTC)[reply]

OK, enough with the indenting. What I'm saying is, MiniDisc is gapless, but ATRAC alone by itself isn't. --KJ 01:14, 9 May 2006 (UTC)[reply]

The gapless part should be mentionned in the Minidisc page, as it is the whole Minidisc "platform" that is gapless when using Atrac, but not the Atrac codec by itself.--Gabriel Bouvigne 07:32, 22 August 2006 (UTC)[reply]

I agree wholeheartedly. Furthermore, there have been reports of non-MiniDisc ATRAC portables that were definitely not gapless, AFAIK. --Kjoonlee 08:02, 1 September 2006 (UTC)[reply]

atrac can suport gapless playback but only if you convert from a format that already have gapless like the red book from a audio cd, which means means that if you convert a audio cd to ATRAC it will have gapless playback in any player that suport the ATRAC format, i know this cause i have a nw e003 that´s not the best walkman, but it works, so the format is gapless, he just can´t take out the silence spots that the MP3 puts on the track, but you can, using a program like NERO wave editor, there you take the silence spot and save it in wave for an example, them you convert to ATRAC and enjoy gapless playback.

Most lossy audio formats aren’t gapless, because of the way they encode the audio in frames of fixed sizes. ATRAC is no exception. MiniDisc is written in such a way that the player “knows” how much of the last frame of a recording is blank and skips it – so the format isn’t gapless, though the way it’s played is. — NRen2k5^(TALK), 15:53, 9 March 2008 (UTC)[reply]

enven if what you re sayng is true, we can still enjoy ATRAC in gapless, and mp3 we can't, ATRAC won! end of history! cause mp3 can oly be gapless in pc in programs like windows media player because he starts the next song before the song is playng end, but if you put it in a portable player this does not work, but ATRAC is gapless in every WALKMAN! so you can enjoy gapless anywhere. —Preceding unsigned comment added by J.U.N.K.E.R.0 (talk • contribs) 21:36, 26 July 2008 (UTC)[reply]

Sure, but how do you play it?

How about a list of computer programs that can play or encode ATRAC3 files? All this information about the codec is pretty much useless if you can’t actually use the codec. —Frungi 16:51, 22 August 2006 (UTC)[reply]

AT3 to MP3

does anyone knows where i can find an AT3 to MP3 converter? or just a windows based AT3 player please? thanks. Wikiprout 02:19, 25 November 2006 (UTC)[reply]

Add Link

I would like to see if anyone would object to me adding a link to our site, The Lossless Audio Blog? Our site tries to bridge the gap between the forums and the various Lossless Audio Guides by providing information on getting started with lossless audio formats as well as current news and information. Because the Wiki pages for lossless audio formats are such a great place for those learning about the various formats I feel that our site compliments this and have heard from a lot of users voicing the same opinion. If you have any questions or concerns let me know.

Thanks for the consideration! Windmiller 12:29, 25 January 2007 (UTC)[reply]

Vendor lock-in?

Do you think ATRAC contributes to Vendor lock-in? Would it help to have a category identifying Category:Non-interoperable systems? The issue is being voted on, please contribute your vote / opinion: here. Pgr94 23:31, 7 February 2007 (UTC)[reply]

ATRAC3plus v. ATRAC3

Below taken out because based on a guess without referance, not good practice for an encyclopedia!

While ATRAC3plus at 64 kbit/s is quite competitive, such a strong result seems quite surprising, considering that another Sony-funded test concluded that ATRAC3 at 132 kbit/s produces similar quality to MP3 at comparable bitrate (see upper section), and that it is unlikely that ATRAC3plus at 64 kbit/s and ATRAC3 at 132 kbit/s would provide similar quality^{[citation needed]}.

Criticisms?

This entry seems to be free from any comparison of ATRAC to other formats, or the availability of ATRAC on non-Sony gear. --24.249.108.133 05:29, 22 August 2007 (UTC)[reply]

Software players?

I browsed the article briefly, and as I understand it there are no software players (i.e. Windows- or Mac-based applications) for this format. Am I correct? Also, the article says, "Sony has all but dropped the ATRAC related codecs in the USA and Europe and their SonicStage powered 'Connect' Music Service (Sony's equivalent of iTunes) on 31 March 2008." Dropped in favor of what exactly? SharkD (talk) 03:31, 25 February 2009 (UTC)[reply]

Transparency

Under the ATRAC1 section the information between the parentheses that has a citation needed tag, I think it's only trying to clarify the definition of transparency in this context. Perhaps if it were differently worded, for example, replacing the text between the parentheses with "transparency meaning that it is not possible for most listeners tell the difference between the encoded sound and it's source". Would this be more NPOV? —Preceding unsigned comment added by The Phool (talk • contribs) 08:20, 7 March 2009 (UTC)[reply]

Comparison and historical significance

This article busies itself ONLY with technical details, probably in far too much detail for an Wikipedia entry (WP:NOTMANUAL).

It should discuss ATRACs role in consumer media, its reception in the marketplace, competing standards (and products).

There is not a single word on how Sony's decision to use a proprietary format probably doomed its efforts to gain market share. Not a single word on the flop that is the minidisc. No general discussion around the folly of trying to hold back the digital revolution.

90.229.34.175 (talk) 07:03, 1 August 2013 (UTC)[reply]

ATRAC9

Used in PS4, PSVita consoles. at9 extension. Can not find much info except FMOD and Audiokinetic Wwise middleware support it. — Preceding unsigned comment added by OxybelisR (talk • contribs) 20:46, 16 February 2015 (UTC)[reply]

External links modified

Hello fellow Wikipedians,

I have just modified 2 external links on Adaptive Transform Acoustic Coding. Please take a moment to review my edit. If you have any questions, or need the bot to ignore the links, or the page altogether, please visit this simple FaQ for additional information. I made the following changes:

When you have finished reviewing my changes, please set the checked parameter below to true or failed to let others know (documentation at {{Sourcecheck}}).

This message was posted before February 2018. After February 2018, "External links modified" talk page sections are no longer generated or monitored by InternetArchiveBot. No special action is required regarding these talk page notices, other than regular verification using the archive tool instructions below. Editors have permission to delete these "External links modified" talk page sections if they want to de-clutter talk pages, but see the RfC before doing mass systematic removals. This message is updated dynamically through the template {{source check}} (last update: 5 June 2024).

If you have discovered URLs which were erroneously considered dead by the bot, you can report them with this tool.
If you found an error with any archives or the URLs themselves, you can fix them with this tool.

Cheers.—InternetArchiveBot (Report bug) 02:55, 4 October 2016 (UTC)[reply]

File extensions for ATRAC

Which file extensions do each ATRAC1, ATRAC3, ATRAC3plus, ATRAC9, and ATRAC Advanced Lossless use?

ATRAC1
- ????
ATRAC3
- at3 ?
ATRAC3plus
- at3 ?
ATRAC Advanced Lossless
- ???
ATRAC9
- .at9

Filename extension .aa3 | .oma | .at3 | .at9

-- Chief38956 (talk) 15:10, 25 December 2016 (UTC)[reply]

Regarding ATRAC Lossless

This section seems to be sourced solely on a bit of ad copy and/or runs into WP:PRIMARY issues. With the format being briefly lived and, if forum posts are anything to go by, limited to PC playback and barely put to use, it seems impossible to find a better source. Should a {{Promotional source}} tag just be tacked on and left to languish? — VariousDeliciousCheeses (talk) 13:29, 18 September 2021 (UTC)[reply]

@VariousDeliciousCheeses: I have added additional sources to the article and made a good structure. You can check again if the article is fine based on your concerns. --Morita Akio (talk) 11:10, 9 May 2022 (UTC)[reply]

Requested move 9 May 2022

The following is a closed discussion of a requested move. Please do not modify it. Subsequent comments should be made in a new section on the talk page. Editors desiring to contest the closing decision should consider a move review after discussing it on the closer's talk page. No further edits should be made to this discussion.

The result of the move request was: moved as requested. Dekimasuよ! 05:45, 17 May 2022 (UTC)[reply]

Adaptive Transform Acoustic Coding → ATRAC – Wouldn't it be better for the title to be simply ATRAC based on WP:COMMON + considering these initials aren't used for another topic + this title format is also used for WAV and FLAC instead of the full names? Morita Akio (talk) 11:09, 9 May 2022 (UTC)[reply]

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

What happened in September 2007?

"All digital Walkman players outside Japan no longer worked with ATRAC after September 2007"

Does that mean 'Outside Japan, all digital Walkman players people had bought stopped playing tracks in ATRAC in September 2007' (similar to the way that Microsoft's DRM schemes have stopped people using things they had bought for their music player/ebook reader at least twice) or 'they could no longer buy new ATRAC-encoded tracks'? The reference probably makes it clear, but it's in Japanese and I don't want to rely on a not very good machine translation. Lovingboth (talk) 21:36, 20 January 2023 (UTC)[reply]