No. That's just plain wrong. Both ADE-based page numbers and Amazon's Location #s have the same flaws, just different scales.
I thoroughly discussed this in
Post #166 and the surrounding posts in the "Sick of Amazon Kindle books without Page Numbers... " thread. I categorized them both as
Byte Methods, and detailed the Pros/Cons of each.
I agree that ADE is a
slightly better Byte Method though, because it is compressed... so it can handle redundant code a bit better, but I wouldn't rely on it for citations in any way.
There is a vast ocean of ebooks + digital documents that are not in EPUB. And there are many very minor versions of ebooks out there (for example, I think I remember using my
Game of Thrones EPUB as an example, where a version I purchased when it came out was a few ADE-pages off from the updated one I downloaded a few years later).
And depending on which tool you use to convert, the output can be wildly different, throwing off the
Byte Method page numbers.
Imagine if a future Calibre or KindleGen conversion changed something very minor like <i> -> <em>, or <i> -> <i class="calibre123">. It wouldn't throw off the total bytes by much, but it will add up throughout the entire book.
Or take a Calibre conversion using in-line styling instead of a CSS Stylesheet. The text is the same, the display is the same, but the total bytes are way different.
What if I opened the EPUB and did a Prettifying on the code? The total bytes change. Imagine a hideously coded book (or a large enough one), and all of that whitespace will add up and throw off the Byte Method.
What if you open the book in Sigil, and it reorganizes the HTML files into subfolders. Links change:
Code:
<a href="Chap1.xhtml">Chapter 1</a>
becomes
Code:
<a href="../Text/Chap1.xhtml">Chapter 1</a>
Imagine something like an Index, with thousands of links going everywhere in the book, and that minor code change adds up. Same book, same functionality, same text... vastly different bytes.